×

AutoCAD

The Choice is Yours

30 Jun, 1998 By: Bill Kramer

---

Over the past several months, I've been asked many times what I think the future holds for AutoCAD programming interfaces. People ask my advice on choosing from the many options and with which one to start when they're learning how to program AutoCAD. The problems with these questions is that there are too many good choices! This month, I am going to depart from my normal discussion of how to program an application and, instead, look into the available application programmer interfaces (APIs).

Program Variations

Developers face a number of good choices for customizing AutoCAD software. AutoCAD R14 comes with a customizable menu system, a macro language (DIESEL), a programming language (AutoLISP) and a Windows-based programming language (Visual Basic for Applications). If these are not enough, you can use the Auto-desk supplied C/C++ language tools (ADS and ObjectARX) or dive into the ActiveX automation of Windows to further enhance AutoCAD. There are lots of good choices!

Making the Right Choice
Let's start with the learning curve and what is required. There are those of you with no programming experience or with some programming background, but not in the available language systems. Good AutoLISP books are plentiful; you can gain valuable knowledge reading them. Visual Basic for Applications (VBA) inside AutoCAD is still new, so not that much has been published. But that is sure to change soon, maybe even by the time you read this. The customization of the menu and the use of DIESEL are well documented. So, if you're learning on your own from scratch, start by reviewing the available literature.

Another consideration for new programmers who know AutoCAD is that only some of the programming options support a command-based programming interface. That means that the command sequences you use to draw in AutoCAD are also used when you are defining a program or macro. AutoLISP, Menu and DIESEL programming all use command streams to accomplish what you want. Command-stream programming is easier for most operators since it is based on the command sequence they already know. The other style of programming is using objects and this requires a different thinking process to quickly get a macro put together. After all, most macros are combinations of commands automated for the user's convenience.

When you're just learning to program inside AutoCAD, the best place to start is in the menu system. This system can provide immediate gratification and has a short learning curve. As variable values are needed inside your custom menu system, then it's time to bring DIESEL and/or AutoLISP into play. For those of you just starting to customize AutoCAD, I have the following recommendation: unless your customization goal is very simple, your time is better spent learning AutoLISP than DIESEL. AutoLISP opens more doors, and as it can also be extended into the objects realm, it will eventually lead to extremely advanced applications. DIESEL can be learned as a jumping-off point into AutoLISP, as the two share most of the same concepts.

All that you need to get started in customizing the menus using DIESEL and AutoLISP is an idea of what you want to do and the time to learn the tools. AutoCAD provides all the tools you need to customize your own toolbar menu system. Online help and the AutoCAD Customization Guide can be very useful in finding more specific information and examples about how these tools can work. But suffice to say, everything you need to begin customizing is just a few menu clicks away after AutoCAD is loaded onto the system.

Until recently, you had to use the system text editor or some other text processor to create robust, advanced AutoLISP programs. As of the writing of this article in mid-April, that situation is changing. Autodesk is previewing a full-screen editor and a live debugging environment. Visual LISP contains significant enhancements for running in the AutoCAD environment and represents a quantum leap forward in the language. Not only has the language been extended, but there are also options to generate ObjectARX-based C++ source code using AutoLISP as a prototype engine. This turn of events is indeed quite exciting, but since the current version is a preview edition, I will not say anything more about it in this issue. I will be evaluating Visual LISP at length in an upcoming issue. (Next month, as a matter of fact!)

From my perspective, AutoLISP is still the best choice for most AutoCAD operators to customize with since they can exploit their knowledge of the command sequences best in that language. However, command streams might not be the way that others want to view an application. Designers who use AutoCAD might want to think in terms of objects they are designing or using instead of thinking in complex command sequences. Let's look at what objects are and then turn to the programming tools available that support the concept and how we can use them.

Real-World Objects
Objects can be thought of as the things being designed. Not just line and arc primitive graphics, but the actual components, such as bolts, nuts, screws and so forth. To put it another way, an object is something from the real world. AutoCAD is a drafting package that is primarily used to draw or model real-world things; thus, it makes sense to combine the two concepts.

When you use AutoCAD, there is a good chance you use basic objects-which most of us know as blocks. Although blocks are constructed of primitives (lines, arcs, circles, text and so forth), designers might actually think of them as models of the things they are using to create the design. A block that represents an object, such as bolt or nut, becomes a model for the object in the eyes of an engineer even though CAD operators might think of them as nothing more than lines and arcs combined into a single name that exists to save drawing time.

But blocks can only be scaled and rotated. They are not capable of preventing you from using them incorrectly. Since blocks only contain primitive graphics and perhaps some variable text in the form of attributes, they do not serve as good objects in and of themselves. Instead, we want objects that know how to behave like the objects they represent. For example, let's say we want bolts to follow specific rules that would be based on the diameter of the hole and the length required. A bolt object in the computer sense would know what its limits are and not allow you to use it incorrectly. This brings us to the concept of object-oriented programming.

Object-oriented programming is the current wave of programming applications and has been for several years. It promotes all of the good programming practices of the past, including modular code, readability and meaningful variables. It also greatly expands on the usefulness of variables since it allows the definition of a new type of information called an object. An object is something that is not just data; it is data that knows what to do with itself. In a way, objects are self-aware, and for many people, this is a difficult concept to swallow. A conceptual example might help to bring this into focus.

Looking at the CAD system, let us consider the entities as objects. A line is an object that contains parameters indicating the start and end point, as well as the color or layer settings. So, the line object contains all the data needed to know about the line, and programmers who have used entity lists can easily see how this object would exist. Now, how a line behaves is what makes up the rest of the object. When it's drawn at specific points, dragged, stretched or manipulated in some way, the line knows how to behave like a line. Never does a line end up looking like a circle or a text object. So does this make the line self-aware? In terms of being a line object in a CAD system, the answer is yes.

Taking that concept to the next level, a collection of lines can be thought of as something like a window frame or a gear hub or some other object in the context of a design. These objects are actually made up lines and other primitive graphic objects, but to designers they represent the items they work with when designing. More than a block, this object would behave based on the rules programmed for modeling something in the real world. Thus, the CAD/CAE/CAM system becomes more useful to the designer. Instead of being a collection of lines and arcs, it is now a tool for designing in a virtual environment.

VBA, ObjectARX and the new Visual LISP are capable of addressing objects. These programming tools all support the object-oriented programming concepts needed to work with objects in the AutoCAD environment. Currently, only ObjectARX has the ability to create new objects; however, the new Visual LISP has the ability to convert AutoLISP code into an ObjectARX executable.

More Advanced Programming
Programming custom objects is more advanced than building command-stream macros and is definitely not for every developer. It does represent the future trend of development in conjunction with CAD/CAE/CAM. Thus, professional programmers who create AutoCAD applications for many users are strongly urged to study this technology. There is much more to ObjectARX than just object-level programming. It also provides the tools needed to develop applications that are much more robust in their interaction with AutoCAD than any other tool currently available.

Presently, there are several applications marketed by third-party vendors (as well as Autodesk) that use custom objects to present component parts. Because of the power and control this technology offers, we can expect a significant increase in the number of developers using it over the long run. The main hurdle is coming up with a solid definition of the objects involved and how a designer would want to use them. This is a hurdle because the C++ coding that is performed to create the custom object is rarely done by designers themselves. More likely, a computer specialist who knows only a little about the application is involved in the coding. In essence, the designer must teach the computer specialist who, in turn must teach the computer, resulting in a rather tedious and error-prone process.

Objects are very useful, even if they are not custom built to our specifications in the AutoCAD system. Other objects exist from other programs, such as words in a word processing document or computations in a spreadsheet. For example, you might want your application to retrieve the value in a spreadsheet cell and place it into a dimension. Or, you might want a text object to be exported to a table entry in a word processor.

Sharing Objects
The presence of these objects on a computer depends on whether the other software is installed and whether or not the operating system supports communication with other programs. Special communications tools could be available if the operating system does not supply one.

In the Windows environment, programs can communicate with each other in several ways. One of them is to treat the items from another program as objects. Through the use of a library called a dynamic link library (DLL), the object's program knowledge is available to our own program. These libraries contain routines that perform a variety of tasks involving the reading and writing of the data, as well as the manipulation of the data. Using these routines, our own program can call upon the other software to do all sorts of activities.

Suppose you are storing data in an Excel spreadsheet. Attaching the object reference library from Excel to your application allows your program to perform spreadsheet calculations. Your program does not have to be sending commands to an active spreadsheet. In fact, your program can open a spreadsheet data file, get or put in the data required and then close it all without the operator seeing anything on the screen. The only requirement might be that Excel is running on the computer. This sort of operation is provided as a result of the DLL system, and this is what AutoCAD also has available for external communication and control.

As mentioned before, there are other methods of communicating between programs that are available in Windows, including Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE) and ActiveX. Each of these are variations of object-level communications between programs. DDE provides for command-line communication, but AutoCAD provides only a one-way link and is not recommended. You can initiate commands to AutoCAD, but you have absolutely no way of knowing if they were serviced properly! The other alternatives are much better.

Accessing other objects in the Windows environment is available to developers using the C++ and VBA languages. If you already know Visual BASIC, then it is logical to look at the ActiveX automation tools as well as the Visual BASIC for Applications module that runs inside AutoCAD. They are slightly different in the way they address the AutoCAD object, but the programming of Visual Basic is consistent with VBA to a large degree. Accessing objects from Visual BASIC is very easy; thus, learning VBA or how to interface with AutoCAD using the reference libraries is highly recommended for programmers who already know BASIC.

The only drawback to the VBA and Visual BASIC approaches is that they are not well suited for menu integration. These tools work best when integrated with another Windows task, such as Excel or when serving as a dialog box input system for graphics output. You can use them for report generation, but the lack of an easy start up from within other programs makes this a potentially cumbersome option to pursue at this time. Another problem with VBA in AutoCAD is that only one project can be loaded at a time. This is not a serious problem but can be a bottleneck for larger applications. However, the menu start up and multiple project situations will most likely change in the near future, and it is strongly expected that VBA will be a dominant programming tool for smaller AutoCAD applications developers and systems integrators.

Finally, for those programmers who already know how to use C++, the choice at first appears to be ObjectARX. This powerful programming tool offers many avenues for system control and tight integration with AutoCAD. In some cases, more coding is required in ObjectARX than might be required in AutoLISP or VBA to accomplish the same task. But in all cases, the ObjectARX program can be made more mistake proof than the others. The reason is that only in ObjectARX does one gain a firm handle, if not complete control, over the events taking place in the system.

So why wouldn't someone who knows C++ want to learn how to use ObjectARX right away? The reason is that the new AutoLISP environment contains a code generator for ObjectARX. Using AutoLISP, program modules can be prototyped and then converted to C++ source code. Since fewer lines of code are often required to define a program module in AutoLISP, the end result will be faster turn-around time in creating new programs.

Thus, my general recommendation is to keep on learning and using AutoLISP for the time being. But do not ignore the other programming tools-they are not only very exciting but offer new alternatives for integration. Of course, if you already know how to use another one of the programming languages, such as Visual BASIC or C++, then you should learn how they can be exploited in AutoCAD first. But I'd still recommend learning AutoLISP. The important thing to keep in mind is to keep on programming, no matter which tool you decide to use. The choice is yours!