To AutoLISP or VBA?

1 Jan, 2001 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 millslot.zip, 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'.