Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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'.