DMM Varkon® Tutorial
A Beginner's Guide to the Varkon
Parametric Modeling and CAD Application Development System
By David M. MacMillan
A conventional CAD or modeling system presents its user with a particular environment for work. The user starts the CAD system, sees the various tools available (drawing areas, pens and drawing tools, geometrical forms which can be drawn, hatchings and other symbols, etc.), and begins to draw. Though there may be more than one way to do something, and though there may even be different "modes" which arrange these tools differently, a conventional CAD or modeling system is essentially a fixed environment given a certain on-screen look and feel by its designers.
Varkon isn't like this at all. In its essence, Varkon is a rich collection of interoperating tools. These tools ("functions"), of which there are a few hundred, are so designed that they work sensibly with each other. (That is, two different tools for drawing geometric shapes both understand the same geometric systems.) However, these tools do not imply any overall screen format, or user environment, or system of menus, or "look and feel."
True, when you type varkon & at the command line a particular Varkon drawing/modeling environment pops up on the screen. This, however, is only a default "project" setup (or "application" setup; the Varkon documentation uses both terms). It presents a simple drawing (2D) or modeling (3D) user environment in which all tools (functions) are available (either through menus or through explicit coding in MBS), but in which only generic uses of these tools are present.
In this generic, default Varkon user environment, it is possible, for example, to draw a line. Let's say, though, that you are involved in diagramming the plumbing system of a building. In this case, you may need not lines, but pipes. Through the MBS programming language, Varkon allows you to define parts such as pipes, and to specify them parametrically. You can therefore design a general "pipe" (think "class" if you're used to object-oriented programming (OOP)) which can become a specific pipe (think "instance" in OOP terms) when specified with its required parameters.
Varkon goes beyond this, however, because it allows you to add this concept of a pipe to the user interface itself. You can create a menu, or modify an existing menu, to allow "pipe" to become a menu item alongside other Varkon and user-defined functions.
A Varkon "project" (or "application") is thus more than a drawing or model. It is a complete Varkon setup which specifies:
Different Varkon projects may thus look very different from one another. The "look and feel" of a Varkon project depends entirely on the way in which its menu systems and types of components have been arranged.
As the Varkon documentation notes, "A well designed [Varkon] application acts as a completely new system with its own user interface and functionality."
To the designer of a project, Varkon is preeminantly a programmer's modeling system. Varkon menu systems are sets of files in a simple format whose items resolve, ultimately, to Varkon functions (built-in or user-defined). The elements of a Varkon drawing or model are not defined as, say, entries in a database. Rather, they are modules of code written in the MBS programming language. Programming a Varkon project is more than scripting macros to simplify user's tasks; programming a Varkon project means creating a unique system built out of the tools Varkon provides.
With the exception of any material noted as being in the public domain, the text, images, and encoding of this document are copyright © 1998 by David M. MacMillan.
The author has no relationship with Microform AB, and this Tutorial is neither a product of nor endorsed by Microform AB.
"Varkon" is a registered trademark of Microform AB, Sweden.
This document is licensed for private, noncommercial, nonprofit viewing by individuals on the World Wide Web. Any other use or copying, including but not limited to republication in printed or electronic media, modification or the creation of derivative works, and any use for profit, is prohibited.
This writing is distributed in the hope that it will be useful, but "as-is," without any warranty of any kind, expressed or implied; without even the implied warranty of merchantability or fitness for a particular purpose.
In no event will the author(s) or editor(s) of this document be liable to you or to any other party for damages, including any general, special, incidental or consequential damages arising out of your use of or inability to use this document or the information contained in it, even if you have been advised of the possibility of such damages.
In no event will the author(s) or editor(s) of this document be liable to you or to any other party for any injury, death, disfigurement, or other personal damage arising out of your use of or inability to use this document or the information contained in it, even if you have been advised of the possibility of such injury, death, disfigurement, or other personal damage.
All trademarks or registered trademarks used in this document are the properties of their respective owners and (with the possible exception of any marks owned by the author(s) or editor(s) of this document) are used here for purposes of identification only. A trademark catalog page lists the marks known to be used on these web pages. Please e-mail dmm@lemur.com if you believe that the recognition of a trademark has been overlooked.
Version
1.7, 1998/06/17.
Feedback to dmm@lemur.com
http://www.database.com/~lemur/vk-project.html
Go to the: