To AutoLISP or VBA?

31 Dec, 2000 By: Bill Kramer

I hear these questions a lot. What's the difference between AutoLISP and VBA? I want to learn how to program AutoCAD, but I'm not sure which tool to learn first. Which one is better?

The quick-and-easy answer is they are both good, and you should learn both. Note that I say this is the quick answer; it is certainly not the quick solution. A more complete answer requires some time and more questions before you can make a fully informed decision. For example, do you already know BASIC? If you do, then VBA will be the fastest one to learn. If not, then do you know any other programming languages? If you do, chances are good it will be a procedural language such as FORTRAN or PASCAL, in which case learning VBA will be pretty easy. If you don't know any programming languages at all, then AutoLISP can be easier to learn.

But it's not just your knowledge and experience in programming computers that should decide what language to learn inside AutoCAD. The next question is more difficult to answer. What do you hope to accomplish? Each language has its strengths and weaknesses. AutoLISP is good at making new commands and creating combinations of existing commands. VBA is good at working with objects including those found in other applications such as Excel and Access from Microsoft. AutoLISP is a list processing system, which allows the programmer to store and manipulate diverse information with ease while VBA has objects that contain data and various utilities for the manipulation of complex things. This is where the question gets sticky. It is hard to answer unless you really know both of these tools well. But the key is to understand what you hope to accomplish and allow that to guide you towards the right solution.

After a while, you will find that my quick answer is right; you will want to learn both languages. You will want to do some things that are easier to handle in AutoLISP with just a few lines of code. While with others, you'll find that VBA will provide the easiest solution to program, such as building a complex application involving lots of dialog boxes. AutoLISP supports dialog boxes, but not to the same degree that VBA supports them. At the same time, VBA provides access to the AutoCAD system at an object level, but it does not lend itself well to using basic AutoCAD commands-something AutoLISP is able to do quite well.

One thing is certain-the two languages do not work well together. That is, you can't write a utility in AutoLISP and make use of it in VBA with ease; it isn't easy to write a utility in VBA and use it inside AutoLISP either. I'm not saying it's impossible; it just isn't easy. The bottom line is once you do start an application using one, you won't be able to switch midstream to the other to solve a problem. You will most likely have to stay with the language you selected initially.

Building a Vocabulary
So, let's discuss some of the differences between these two languages from a technical level. As mentioned before, AutoLISP is a wonderful tool for integrating logical constructions with traditional AutoCAD commands. You can combine AutoCAD commands into a script with conditional logic and loops to create powerful commands of your own design. These commands can be used to automate common tasks as well as solve computations in order to arrive at a result. There are times when command-type thinking is easier to program than object-level thinking. A quick example that points this difference out clearly is the lack of a break type method in the polyline object. If you want to break a polyline, you must do the math and update the object. The same is true with the Extend and Trim commands. These commands are not available as methods for entity objects in the AutoCAD object system at this point in time. They may appear at any time in the future, however. This is the beauty of objects!

Objects do have advantages over commands in most cases though. When you issue a command, you may or may not have the ability to select the objects you want to manipulate directly. Instead you must rely on the object selection mechanism at work in AutoCAD. Objects do not have that ambiguity. When you specify an object by reference, it is pretty clear what object you mean to manipulate.

Object-level manipulations are available in Visual LISP too. Using the (VL) extensions found in Visual LISP you can change object properties and invoke object methods when needed. You do have to use object references that can be created by converting existing entity names or by creating the objects directly. In most cases an experienced AutoLISP programmer will not need to use the objects. But there are times when they sure come in handy.

Another point Visual LISP (AutoLISP) gets over VBA is the closer proximity to the AutoCAD system. VBA is not native to AutoCAD-it is an add-on language that works the same in other environments such as Microsoft Word and Excel. It is also similar from a programming point of view to VB (Visual BASIC) in how it works with AutoCAD. Visual LISP only runs inside AutoCAD and as such takes advantage of a closer working relationship with the software.

You can find an example of this difference when prompting the user at the command line. In Visual LISP you use the (PROMPT) or (PRINT) expressions. In VBA you must use the Prompt method that is part of the Utility object that is part of the Drawing object. The following lines of code will send a prompt to the command line of AutoCAD. Visual LISP is first; VBA is second.

(prompt "\n starting.")

thisDrawing.Utility.Prompt Chr$(10) & "starting"

Two things are immediately obvious. In Visual LISP, the "\n" escape sequence is used to start a fresh line at the command window. VBA uses the function Chr$(10) and must concatenate it to the front of the prompt string using the "&" operator. The other difference is the amount of typing required to access the prompt method of the utility object versus just using the command.

In AutoLISP, the (PRINT) expression could have been used and the "\n" escape sequence dropped since (PRINT) moves to a fresh new line before outputting the value. Another feature of (PRINT) is that it will output any data type while only strings can be used in the (PROMPT) function.

For the Utility object methods in VBA as well as the (GETxxx) functions of AutoLISP, you must use strings at all times. AutoLISP contains several different functions that will convert the type of data you would use into strings. (RTOS) converts real numbers to string and (ITOA) converts integers. VBA provides two numeric conversion functions, STR and FORMAT. The STR function returns a string with one subtle nuance: a space is added to the front of the string when converting a non-negative number. That is, str(-1.1) returns the string "-1.1" , and str(1.1) results in " 1.1". FORMAT allows you to specify the conversion format specifically. For those just learning VBA, see the FORMAT function description in the online help, it offers plenty of examples showing how data can be converted for output.

Balancing the Scales
The fact that AutoLISP can be integrated at the command level further tilts the scales in favor of AutoLISP for AutoCAD customization. You can define new commands using AutoLISP just by defining the function with the characters "C:" as the first two characters of the name. Since they will act just like AutoCAD commands, "C:" functions are called "Command functions." VBA has macros, and you must run the macros from the VBA program manager.

The fact that VBA does not run from the command prompt (or simple menu macro) does not present a major problem. You can start the VBA program manager using AutoLISP and then invoke the macro in the same manner. When using the (COMMAND) expression, make sure you use the "-" dash at the front of the command as in the following:

(command "-VBALOAD" "mymacros" "-VBARUN" "mymacro")

If you do not include the dashes, a dialog box will appear for the user to load the VBA modules and run the macros. In most cases that is not the desired process. Instead, the macros are loaded and run in a command function thereby giving the illusion of a command-based VBA module. Thus, what at first appeared to be something in strong favor for AutoLISP turns out to be not much of a concern. This is not unusual in programming-once a flaw or hole is identified, a work around is often created.

In addition to allowing for a startup via AutoLISP, VBA also has a nice set of functions for reacting to the drawing and working with multiple drawings at the same time. You can do some of this in Visual LISP, but not as easily as you can in VBA. Reactors can be attached to drawings and even embedded into template drawings, allowing your drawings to have programs built in for any number of reasons. Visual LISP does not have this same ability without some clever programming or menu manipulations.

Another area in which VBA beats Visual LISP is data types. VBA has many more data types than Visual LISP, including some useful ones such as Date and Time. In Visual LISP dates and times are stored as strings or as numeric values. When you access the system date information in a drawing via the system variables, you will get real numbers representing Julian calendar days.

The manipulation of dates and times in VBA could not be easier. The FORMAT function can be used to create output formats of almost any description, and you can perform basic numeric comparisons and differences with the values. Thus, you can store and manipulate your own time-keeping information in a format that is simple to work.

I've heard die-hard AutoLISP programmers proclaim that VBA does not support lists as LISP does. This is true. But VBA does support Variants, which are much like LISP symbols in that they house any kind of data. Variants allow VBA to work with variable data and constructs, but they are not as powerful as lists in LISP. Lists can be used to store many different types of data and then manipulate them quickly with a few lines of code based on (MAPCAR), (FOREACH) and (APPLY). But these kinds of programming styles require some time to master, and most beginning programmers will not miss having access to list structures when using VBA.

Frankly, list processing is not as interesting as object manipulations are for programmers. In VBA (and in Visual LISP) you can link with other systems supporting objects. The ActiveX interface of Windows is an object-oriented process-to-process communications system for programmers. It allows your VBA program running inside AutoCAD to take over and run Excel or some other task supporting automation. And since Excel supports VBA, you can drive AutoCAD from inside an Excel worksheet. Multiple process automation has awesome potential when you start to think about it.

If you download the Zip archive, you will find it contains two programs: one in VBA (with a DVB extension) and another in Visual LISP (with an LSP extension). These functions both do the same thing: they ask the user to define a basic mill slot from parameters and then proceed to draw one. The mill slot can be placed at any angle and can have a radius corner (90 degrees) or a full semicircular end cap. These examples show several of the differences between VBA and Visual LISP styles of programming. Perhaps the most striking is the way in which the lightweight polyline is created. In VBA the object is defined as a series of points. The bulge factors are supplied after the initial object is created. The Visual LISP example simply uses the PLINE command to output the points and arcs as they would be supplied from the command prompt. From a programming point of view, the Visual LISP version is easier to create because you don't have to know anything about bulge factors and how they are used in polyline objects. I could have used the (Entmake) expression in Visual LISP and defined the bulge factors in an entity list, but the command-based version is much easier to code.

If you have followed along thus far, you can see that Visual LISP and VBA are pretty well balanced. Where one is weak, the other is strong. While VBA supports some new concepts for AutoLISP programmers, it also has some pitfalls that can make a simple task complex to program. I tend to favor Visual LISP in most cases because it offers more options, and I have a lot of experience using it for AutoCAD customization. But many times I'll use VBA for client applications because it will be easier for them to maintain, and it provides an easy interface to some other automation module. Many of my clients do not have extensive experience in customizing AutoCAD, but they have some background in the BASIC language. As a result, they use the VBA application I write for them, and they feel comfortable that they can make elementary changes to it as needed in the future.

All of the reasons presented thus far are why I recommend learning both Visual LISP and VBA. But again, this also hinges on what you want to do with the tools. Learning just one is okay, but you will not know what you are missing from the other and as time marches forward, they are bound to collide. Your first step will probably be learning how to run LISP expressions from VBA or run a VBA custom class method from Visual LISP. From there, who knows what will be next!

Where to Start
In order to determine which language to tackle first, do some simple self-evaluation. If you know the AutoCAD commands well and want to automate the process of using them, then Visual LISP is the first step to take. If you don't know AutoCAD but are a computer programmer who understands how objects work, then start with VBA. If you are a C++ programmer, you may want to start with VBA just to see how the objects all tie together and then take those lessons to ObjectARX (a C++ library for the construction of DLLs that run in the same memory map as AutoCAD itself). The ObjectARX option was not considered in this article because you must use an external C++ compiler and obtain the ObjectARX toolkit from Autodesk. Visual LISP and VBA are supplied with AutoCAD 2000.

And a final word of advice for those who want to learn how to program AutoCAD: look for books and magazine articles that have examples. [Editor's Note: For two of the finest such books, see AutoLISP Treasure Chest by Bill Kramer (MFI Books) and AutoCAD VBA Programming by Bill Kramer and John Gibb (MFI Books). Also see Using Visual Basic with AutoCAD, Second Edition, by Andrew Roe (Delmar).] And search the Web for even more examples. The online help available in Visual LISP and VBA is a tad confusing for the beginner; some of the functions are documented from a VBA point of view and others are documented from a Visual LISP point of view. No matter which language you are using, there is a good chance you will stumble into help for the other language since they are closely related. So, I strongly recommend seeking out a book or two. There are numerous options to select from, and a good book store should carry a few.

Many choices exist, and each has advantages. Whatever one you choose to tackle first, at some time you will likely want to learn all of them in your quest for more knowledge. In the mean time, keep on programmin'.

About the Author: Bill Kramer