×

AutoCAD

Comparing Visual LISP to PowerCAD's FLISP

28 Feb, 2003 By: Bill Kramer

---

The LISP language has been an important part of AutoCAD since it first appeared over a decade ago. During that time hundreds of thousands of macros have been created that enhance the operation of AutoCAD. Some of these macros are quite sophisticated and, as AutoLISP has grown inside AutoCAD to become what we now know as Visual LISP, some very powerful applications have been created. A large array of third-party solutions are available for a variety of tasks, making AutoCAD the powerful tool it is today. There are other programming languages that are wonderfully suited to programming CAD applications; however, LISP remains a favorite for many due to the succinct nature of the resulting code--that is, fewer lines of programming are required to accomplish most tasks.

For many years it seemed as if LISP inside CAD was a curious macro language choice of AutoCAD. Some feeble attempts were made to incorporate LISP into other CAD platforms, but they mostly resulted in the programmers wondering why they even went that way, given that the macro languages already available did everything they needed. In the mid-1990s, a product from Germany appeared in the U.S. market with a version of LISP built in. This product was well programmed and appeared to run just like AutoCAD, but the company paid close attention to make it different enough so the product was not an infringement on Autodesk.

PowerCAD Redux
PowerCAD is a microcomputer-based CAD solution that provides many of the same features as AutoCAD. It even uses the same command sequences and entity types. And it includes a variation of LISP known as FLISP that is claimed to be very similar to AutoLISP, thereby preserving existing work from that platform.

What intrigued me the most about PowerCAD was its position in the market. PowerCAD is priced as a lower-end CAD system and runs on more modest computers than does full-featured AutoCAD. And it runs on Pocket PC systems. What's more, the Pocket PC version supports the FLISP language for customization. Now that is very interesting!

Here are the results of my tinkering with and testing Version 5.2 of PowerCAD. I wanted to get a feel for what it would be like to port small and large macros from AutoCAD to PowerCAD, and I turned to my vast library of past projects to see where I could break it.

Putting FLISP to the Test
FLISP claims to be like AutoLISP. That means it does not have all the features of Visual LISP, including the powerful ActiveX and object-oriented tools. But it does have extensions for many of the other functions needed in the creation of applications; thus, the lack of objects is not critical unless your application depends on them exclusively. FLISP uses the entity name and entity list approach to working with entities. If you have been programming AutoCAD for a number of years, you could say that FLISP is a lot like AutoLISP as found in Release 14.

Although no longer a supported product from Autodesk, Release 14 was a popular platform and had a large library of AutoLISP macros written for it. The AutoLISP of Release 14 was quite powerful in that you had access to all the entities in a drawing, the drawing system variables, a full-featured programming language, and extendibility through the ADS library into C. For FLISP to rival AutoLISP of that time, it would have to be quite powerful.

I started with some macros from past CADENCE issues. Several were simple routines that manipulated lists of numbers, while others were more complicated programs involving entities, files, and dialog boxes. Virtually all of them ran the first time. The only differences that needed to be addressed were the dialog boxes. None of the dialog boxes from AutoLISP worked without significant revisions.

FLISP makes some significant departures from AutoLISP when it comes to dialog box processing. FLISP has matching functions for the majority of tasks associated with dialog boxes in AutoLISP, but they all have different names. Where you would use (SET_TILE) in AutoLISP, you use (DLG_TILESET) in FLISP. So you would think that simply changing the symbol names or building a library of phantom functions might be an easy way to remedy this difference. However, there is a more subtle difference that needs to be addressed.

FLISP Differences
When you call the function to start the dialog activity called (DLG_DIALOGSTART), you supply a string that contains an expression for defining the elements in the dialog box. Normally this string is a function name, which is where you perform all the dialog box preparation work such as loading up list boxes with data and setting associated actions.

FLISP does not use DCL files; however, the programming is the same. Keys are used to reference specific controls in the dialog box. DLG files in FLISP have more formatting control options than DCL files. As such, an editor is provided for manipulating the DLG files and creating the layout. This is a welcomed feature over DCL, which is still a text editor job to define a dialog box.

The dialog box system of FLISP is superior to the DCL system in AutoLISP. The only thing I've found lacking is that the DLG file is not documented.

Editing a dialog box is easy in FLISP as you use an editor to place the various items. As the dialog box is created you can use a text editor to create the corresponding LSP source code for the dialog box components. It is not as easy to use as Visual BASIC, although I suppose you could use the Visual LISP editor at the same time to create the LISP source code.

A really nice feature demonstrating the extensions of FLISP is in how list boxes are handled. A list box is a control inside a dialog box. FLISP list-box controls return the value from inside the list displayed. I like this feature as it makes working with list box contents a little easier and faster. The values can be sorted in the list control without worry about an associated data list needing to be sequenced at the same time. All that is needed to keep track of related data is an association list with the text from the list box as the key.

Another important difference I discovered in FLISP versus AutoLISP is in how COMMAND is used in a macro. A common practice in AutoLISP is to start a command, then do some processing, and then return to the command expression. The classic example for this is to create a polyline from a list of data points. The polyline command is started, the points are then output inside a loop, and the command stream then ends. In FLISP, however, you must finish the command when you start it in a single expression.

For situations where the command processor needs to remain open in a command while the program iterates, the recommended alternative is to go directly to the entity data lists. This approach is recommended in AutoLISP and required in FLISP.

Due to the lack of adequate feedback in case of errors, the command processor should only be used when absolutely required as when using the OFFSET command. This means that the utility I just mentioned--to write a polyline from a list of data points--is best written using (ENTMAKE) to create the POLYLINE and VERTEX objects (or by building a large entity data list for a LWPOLYLINE object).

A very powerful feature of both AutoLISP and FLISP is they can be extended through the use of a C library. This allows the C programmer to add new functions to FLISP that take advantage of the operating system or some other aspect of the computer.

How FLISP Fares
After porting several dozen utilities to FLISP, my impression is quite favorable. Of the several dozen functions I tested, only a few failed in the first try. And they were all due to a poor use of the command processor when ENTMAKE and ENTMOD would have been better suited to the task. Now, in fairness, those test routines were written before ENTMAKE and ENTMOD were available. This underscores that you cannot expect to run anything just because it is old and ran in an ancient version of AutoCAD. FLISP has its limits in that direction as well.

FLISP is not Visual LISP. Programs that take advantage of the advanced features in Visual LISP will have difficulty porting to FLISP. Features such as reactors, custom commands, and other tools related to the Active X system are simply not available in FLISP. Instead FLISP is comparable to AutoLISP. With the primary difference being the way dialog boxes are defined and programmed. Most programs written in AutoLISP will run in FLISP with minimal changes. I found the porting to be pretty easy once I had a handle on the dialog boxes and how they were programmed.

After working with FLISP for a while, I found that I still prefer Visual LISP. But that's because I like VLIDE. Until next time, keep on programmin!