Bill Kramer
Visual LISP is Autodesk's new objectarx development environment for AutoLISP programmers. it offers power at a low price and a host of other valuable features.
Let's get the details out of the way first. Visual LISP is an ObjectARX application, which means that it runs inside AutoCAD. The initial release of Visual LISP requires AutoCAD R14 and, because it is an ObjectARX application, new build updates will likely be required for each release of AutoCAD. Based on Vital LISP, originally from Basis Software, Visual LISP consists of several modules that the developer uses to create new applications. These modules include a text editor devoted to LISP program development, a LISP console, project window and more. Although some of the modules are like other developer studios, they are not exactly the same. The reason is that LISP is an interpretive or evaluated programming system and not just a compiled programming language.
The price of Visual LISP is currently set at $100, and I'd like to mention that it is not for every AutoCAD user. Casual AutoLISP programmers should not consider the use of the program except for certain key features. In fact, even experienced AutoLISP programmers need to spend a little time with the product to get truly comfortable with its features, and that is not because the software is unfriendly. The program is very user-friendly for serious application programmers. So how do you know if you are serious enough? Check out the main features of the system and see if anything sounds tantalizing. If so, you should seriously consider purchasing the product.
The New Way
Installation of the software is quite painless. In Windows, the auto-run
module launches into the installation immediately when the CD is inserted
into the computer. The program components install into a directory by
themselves and do not modify AutoCAD in any way. In fact, you can run
AutoCAD as usual and only call up the product as you need it. This is
an important aspect of Visual LISP and represents a trend in the general
methods by which new features can be added to AutoCAD. The ObjectARX system
allows AutoCAD to be extended without changing the core product itself.
Systems managers will likely approve this aspect of the product, as it
reduces the downtime required when adding new features and saves testing
time because the new features do not change basic system operation.
If this concept escapes you, consider the following true story. Several years ago there was an enhancement to AutoCAD called the AutoLISP Compiler (yes, it is a great-grandparent to the current Visual LISP). The AutoLISP Compiler was mostly used in Europe and did improve the speed at which AutoLISP programs ran. However, it did not gain popularity in North America because Autodesk did not support it and there were differences in the way the LISP evaluator worked (albeit subtle ones). The problem was centered on the fact that the compiler replaced the AutoCAD module that performed AutoLISP functions. Thus, all existing programs that worked well under standard AutoLISP did not always work when the new evaluator was introduced. The introduction of such a change required careful analysis before implementation when existing systems were in place and operational. Compare this with the ObjectARX version that does not replace AutoLISP in any way. Because the tool does not replace anything, but is instead just a new way of doing things, it is easier to accept. Future productivity tools from Autodesk and many third-party developers will undoubtedly follow this model.
Will My Program Run Faster?
There are two sides to the time savings issue in relationship to a programming
tool such as Visual LISP. A topic of interest to many programmers is speed
of execution, or more succinctly, "Will my program run faster?" The answer
is basically an affirmative-with some caveats. There are subtle differences
in the way the individual interpreters evaluate program code, and, as
a consequence of the way they are built, programs will run at different
speeds. The style of the programming will influence the speed more than
anything else. For example, when I tested the speed of Visual LISP versus
AutoLISP, I found a case where AutoLISP was faster. AutoLISP handled a
recursion problem faster than Visual LISP. The example used was the common
factorial computation function. Even after the Visual LISP program was
compiled into an ARX module, AutoLISP was slightly faster at solving the
problem. However, in the other tests using more common iteration structures
and involving floating point arithmetic, the Visual LISP program was two
to three times faster on a regular basis. You can expect AutoLISP applications
that involve numerical work to run faster in the Visual LISP environment
(once properly prepared).
The time one spends developing and maintaining programs is probably more important than execution-speed time savings. In this regard, Visual LISP offers some significant improvement over the AutoLISP programming tools you are probably using today. (Master programmers who have written their own tool kits are exempt, of course!) The editor environment is very friendly for program entry and the color-coding makes existing code very easy to read. In fact, there are several features in the editor that make working with AutoLISP code very nice. If you are using a generic editor to maintain your code, the editor features alone are well worth the price of admission. Let's take a look at the editor features that go beyond being a basic editor. These are the features that make this editor particularly strong for working with AutoLISP code.
The VLIDE
There are several windows, and programmers used to the visual developer
environment will have little trouble learning how to navigate the Visual
LISP Interactive Development Environment (VLIDE) running inside AutoCAD
R14. For those who are new to programming systems in Windows, this system
may at first appear complicated. But like driving a car, you will learn
which "instruments and indicators" deserve attention and which do not.
Context-sensitive help and tool tips aid considerably when learning to
run the interface. Most of the programmer's time will be spent in the
coding and debugging phases, which is where many of the features in Visual
LISP can be found. Visual LISP contains numerous debugging features, such
as parentheses balancing, automatic formatting, symbol protection, and
others, all of which will result in a reduction in the time required to
get a program working.
Parentheses Balance Check
The first debugging feature I tested was parentheses balancing. Having
a good tool to check parentheses can save a lot of time when debugging
code that is either missing a parenthesis or has too many. In the past,
I've always used a program that read an AutoLISP file and then generated
a report. Using Visual LISP's feature is much easier, however. Place the
cursor anywhere in the source code, then move forward through the balanced
sets of parentheses by pressing the [Ctrl-]] key combination. Move back
through the balanced parentheses using the [Ctrl-[] key combination and
add the [shift] key to either set to have the entire balanced area highlighted.
This made searching for those pesky missing parentheses a breeze! And
because this is not an external utility, but is integrated directly into
the text editor, corrections can be applied immediately when the problem
is found. All in all, this feature is wonderful if you are like most of
the world and have trouble balancing parentheses in complex sequences of code.
Automatic Formatting
Something that caught my eye right after checking the parentheses balancing
tool was the automatic formatting option. This feature takes AutoLISP
source code and reformats it so that it follows a prescribed presentation.
When used, all programs look the same in terms of the way lines are indented
and dangling parentheses are handled. In situations where programs are
supplied from other programmers, the format will most likely be different
than your own. Another possibility is that code you wrote a year (or more)
ago might look very different than the code you are writing now. The automatic
formatting feature will provide a standard look to all the code you work
with, which means you do not have to decipher some foreign style of coding
to solve a bug. And on top of that, the formatter is programmable!
Figure 2 (figures unavailable on the web) shows the code window of a poorly formatted section of code I loaded into the system. The code in the window was selected and the format tool was run. After running the formatting feature in the editor window, the code appeared to be much more readable, as shown in Figure 3 (figures unavailable on the web). This feature can save a lot of time and programmers who work with other people's code can attest to that fact. Even if you don't work with code from other sources, having a consistent presentation of the program in the editor can be a valuable time saver because it does the formatting work for you.
Figure 4 (figures unavailable on the web) shows some of the programmable aspects of the formatting option. You can set the indentation levels and set other aspects of the formatter to match your preferences. One nice thing about the automatic formatter is that all the code you work with will have the same look, making it easier for you do what is needed.
Color-Coded Text
Figures 2 and 3 also show the color-coding features of the text editor,
which is something you cannot help but notice the first time code is loaded.
The default colors were used for this review, but you can set them to
whatever scheme you want. Although the use of colors is new to most AutoLISP
programmers, it doesn't take long before you are used to them and wonder
how you ever read and wrote code without them in the past.
Here's why. When you are entering code or searching for a typo, the AutoLISP subrs and regular symbols are easy to spot. During entry of the program code, this feature can help identify typographic errors. If you are typing the name of a subr and it does not turn the appropriate color as you finish typing it, then there is an error in the entry. You get used to looking for the color change as feedback that the typing was okay when running the editor. Comments and other code features stick out when using the colors and it is amazing how quickly your eye is trained to look for the right stuff.
Color coding also helps preserve the integrity of the code. Something I've seen often in other programmer's code is the improper use of a symbol. For example, even though the expression (setq Length 1.0) is a valid AutoLISP expression, it will cause the link to the list (length) subr to be broken. This causes any code that calls the (length) subr to fail with an unknown function error. The color coding and syntax checking features of Visual LISP aid in finding these sorts of mistakes and, as anyone who fixes programs knows, finding the problem often takes 90 percent of the programmer's time!
Automatic Parentheses Balancing Act
While we are on the subject of error checking, Visual LISP provides some
nice features to shield the programmer from making mistakes. Parentheses
balance checking is performed when reformatting the code window. If something
does not balance, Visual LISP finds it and lets you know. Figure 5 (figures
unavailable on the web) shows the pop-up warning that will appear when
a missing parenthesis is detected. Although Visual LISP offers to insert
a matching parenthesis where it thinks it ought to go, my testing showed
that it was usually wrong. This didn't surprise me, as it is quite a task
to add a "You know what I mean" type processor to the evaluator! But it
was still nice of the software to ask if it could help out.
Animation Feature
After loading the code window contents to the console, the code can be
run with the animation feature engaged. The animate feature will highlight
each expression as it is evaluated and serves as a powerful debugging
tool. The duration of the highlight over the running code is programmable
so that you can speed up the animation code display. You can also choose
to animate only a section of code by setting break points where you enable
and disengage the animation, thereby offering a valuable tracing system
to locate problems in the code.
Symbol Protection
Figure 6 (figures unavailable on the web) shows the result of running
bad code. In this case, the symbol length is being set to a value. Since
length is a symbol normally used in AutoLISP for determining the length
of a list, it is not advised that the symbol be set to something else.
Visual LISP gives a warning and provides an opportunity to break out of
the program at that point. When checking someone else's code and integration
problems between systems, this feature can help to quickly weed out bad programming.
Missing a Quote?
In Figure 7 (figures unavailable on the web) the color coding scheme comes
to our aid in locating a missing double quote that terminates a string.
The magenta color indicates that we are in the middle of a string definition
and it's easy to spot that something has gone wrong. As soon as the missing
double quote is added to the string entry, the remainder of the code changes
colors. If that is the only problem string, the remainder of the function
code should look normal (blue for subrs, black for user symbols and so forth).
Apropos Feature
Turning away from working with other people's code and looking again at
productivity features, Visual LISP has several that aid program entry.
As with most tools, you will get better at using them as you practice.
The Apropos and matching features can be used to save keystrokes during
original program entry. When you are typing in the name of a function,
such as one of the selection set functions which all start with the characters
SS, you can hit the [Ctrl] + [Shift] + [Space] key combination to have
a list of symbols presented that match the starting SS characters. Use
the arrow keys to select the one of interest from the list and then, if
you are unsure as to the syntax or parameter values, select the help button
to go directly to the help information for that subr. This feature comes
in very handy when working with the expanded set of subrs provided in
Visual LISP. Since they all start with the characters VL and are sometimes
long names to type, the feature can save a lot of time in this regard.
Figure 8 (figures unavailable on the web) shows a list of VL functions
for selection in the window.
Language Enhancements
Visual LISP sports a large number of enhancements over the AutoLISP language.
Table 1 shows a summary of the new subr names. This is only a partial
list, as there are well over 750 new symbols that were found in the APROPOS
search for the prefix letters VL. Many of these subrs fill in the blanks
left by the AutoLISP system. For example, several functions allow directory
management of the disk system. Many experienced AutoLISP programmers might
have found alternatives with ADS and ARX to solve file management problems,
and it is nice to finally see these features included in an advanced version
of the AutoLISP language. There are also enhanced list manipulation tools
and string utilities that can be found in the general set of improvements.
Because Visual LISP is an ObjectARX application, it can expose the internal structure of the AutoCAD database to the programmer. That means the Visual LISP programmer has access to the objects with their methods and properties. Of primary interest are the methods. Methods are libraries of functions that perform specific tasks with the objects in the database. There are methods for updating the properties of the objects (things such as layers, colors, points, radii and so forth) and there are methods for doing things with the objects such as locating the intersection of one object with another.
Does this mean that Visual LISP is an object-oriented programming system? No, it doesn't. Visual LISP does not meet all the criteria of an object-oriented programming language (encapsulation, polymorphism and inheritance); however, that does not preclude it from working with the AutoCAD objects themselves. The reason is that these objects have been made available to Visual LISP through the ObjectARX system that is running the environment. Thus, the object methods in AutoCAD are available through the bridging functions that are part of the system. The trade-off is interesting. In AutoLISP, the traditional method is to either generate command streams or send entity lists into the system for processing. Entity lists are scanned by the same procedures that handle DXF importation and are slowed down as a consequence, but not nearly as much as the command stream, which must perform all user error checking as well. ObjectARX uses direct object manipulation, which is indeed much faster. However, Visual LISP is an evaluated system that must set up the ObjectARX accesses so the speed is not nearly as much as it is when using ObjectARX alone. So which is fastest of the LISP versions? The Visual LISP system is two to three times faster than AutoLISP in this regard, and it has better control over the objects themselves.
Reactors
Nowadays, the internal database includes more than just graphical data.
In fact, it includes call-back function links allowing your program to
be notified when a change is taking place. This feature, called Reactors,
is something new for most AutoLISP programmers. Now they have access to
the happenings inside AutoCAD instead of having to be initiated only by
user activity. What this means is that you set up functions to serve as
callback functions when a particular event happens inside the system.
The function is called when the event happens, no matter who initiated
it. In most AutoLISP programs, the user starts a process via the command
line or a menu pick. The function(s) then run and when they are finished,
control is passed back to the command system. Reactor functions, however,
are called by the system when an event has taken place.
Reactors are very interesting indeed. You can have your functions called whenever something of importance takes place inside AutoCAD, such as a new entity being added or an existing one being modified in some way. There are four groups of reactors inside the AutoCAD system. The first group is the linker reactor, used to link up with other ARX programs. The editor reactors notify you when a command is started or the drawing system is being saved or abandoned. Database reactors are activated when things happen to the drawing database, such as an object being added or removed. Finally, object reactors are attached to individual objects in the drawing database and are called when these objects do something of import.
When assigning functions to reactors, the program supplies a reserved key name, such as :vlr-objectErased, which is the symbol used to attach a reactor to a particular entity object. In this case, the call-back function will be evaluated whenever the object in question is erased. Something to note about reactors is that you do not have the ability to veto the operation. For example, if you have attached a reactor to notify you that an object is being erased, and then that object is erased through some method, your function cannot stop the process. Should your function have an error, AutoCAD simply ignores it and continues with the operation at hand.
Compile into ARX
One last feature that I want to mention is Visual LISP's ability to run
as an ARX program. When you prepare a program for use in AutoCAD there
are three alternatives. You can create a VLX environment version, an ARX-only
version, or an ARX with ActiveX version. VLX programs require the Visual
LISP run-time evaluator to execute. Programs are distributed as FAS files
along with the VLX module. The main advantage of using VLX builds for
program distribution is that updates can be supplied to users as FAS files,
which are significantly smaller than ARX files. If you want to distribute
your program modules as ARX modules, use one of two options. The ActiveX
build method is employed when you are using the ActiveX features of Visual
LISP. The ARX output file combines all the project elements including
the LISP code, dialog boxes and so on. The combined file tends to be over
500 kilobytes in size, because it has everything in it. If you are working
with a closed application, this approach works fine; however, when working
with small modular applications, the number of ARX modules can get excessive
and compromise overall system performance. The other problem with distributing
ARX modules is that when the AutoCAD version changes, the ARX modules
must be updated as well. As it stands currently, the VLX module will also
have to be updated when AutoCAD is changed; however, that situation might
change as Autodesk gets even closer to achieving a completely dynamic,
object-oriented system.
Visual LISP vs. AutoLISP
This has been a quick introduction to Visual LISP. There is a lot more
behind the software than first meets the eye, and it is always fun to
explore the utilities and learn even more about AutoCAD, AutoLISP and
the programming environment in general. If you are a serious AutoLISP
programmer, consider obtaining the Visual LISP software. The editor features
alone justify the price, and the increased access to the system certainly
makes it a lucrative tool. More important to many, though, is that Visual
LISP clearly signals that Autodesk still stands behind AutoLISP and that
language tool as a method of customizing the system. For those who have
invested tremendous time and effort in building advanced AutoLISP systems,
this is very welcome news. You can choose to continue with AutoLISP without
fear that it will go away in a future release. When you are ready, you
can graduate to Visual LISP for more serious systems development.
I strongly recommend that AutoLISP programmers obtain the Visual LISP software; however, I recognize that it is not for everybody. The system is not as easy to use as AutoLISP, where things are simply typed into the command line. However, Visual LISP is not as basic in structure as AutoLISP, and thus allows more advanced applications to be written. For those who have used Vital LISP or even the AutoLISP compiler in the past, this is the next generation-and it's a lot better.
Bill Kramer has more than 20 years experience customizing CAD/CAM/CAE systems. Reach him at bill@autocode.com via the Internet.