Tag Archives: AutoLISP

LISP programmers, have your say again

Autodesk wants your input again in its annual API survey. This used to be a closed survey for Autodesk Developer Network (ADN) members, but has been open to all for the last few years. If you do any AutoCAD-based development at all, I encourage you to take part. That includes those of us who do most of our development in LISP.

Here’s the direct link to the survey. As you can see if you click the link, there’s a lot of stuff in there that assumes you’re keen to get developing for AutoCAD WS. If you’re not quite so filled with Cloudy enthusiasm and would prefer Autodesk to expend its resources elsewhere (on fixing and improving Visual LISP, for example), please fill in the short survey and say so. It closes on 22 June, so you only have a week.

Why bother, when it’s obvious that Autodesk is determined to ignore to death its most popular API regardless of whatever anyone says or does? I’m not sure, really. Maybe I’m an eternal optimist. (Ha!) Maybe I just want them to at least feel slightly guilty about sticking their fingers in their ears and going “LALALALALA! NOT LISTENING! WE HAVE A VISION, NOT LISTENING! LALALALALA!”

The best feature ever added to AutoCAD is…

LISP. I have now closed the What are the best features ever added to AutoCAD? poll, and the winner is AutoLISP/Visual LISP, by a long, long way. I don’t always agree with the majority view expressed in the polls here, but in this case I wholeheartedly agree. Adding LISP was the biggest and best thing that ever happened to AutoCAD. Autodesk owes an enormous debt of gratitude to John Walker for incorporating the work of David Betz, who was of course standing on the shoulders of John McCarthy. It’s a crying shame that Autodesk has been so terribly neglectful of Visual LISP for over a decade.

Here are your top ten “best ever” AutoCAD features:

  • AutoLISP / Visual LISP (32%)
  • Paper / Model Space / Layouts (21%)
  • Xrefs (20%)
  • Copy / Paste between drawings (19%)
  • Dynamic Blocks (16%)
  • Object Snaps (15%)
  • Layer Visibility per Viewport (12%)
  • Undo (12%)
  • Grips (12%)
  • AutoSnap (9%)

Something interesting I noticed is the age of these features:

  • AutoLISP / Visual LISP – 1985 (significantly improved 1999)
  • Paper / Model Space / Layouts – 1990 (significantly improved 1999)
  • Xrefs – 1990
  • Copy / Paste between drawings – 1991
  • Dynamic Blocks – 2005
  • Object Snaps – 1984
  • Layer Visibility per Viewport – 1990 (improved 2008)
  • Undo – 1986
  • Grips – 1992
  • AutoSnap – 1992

The youngest feature here is 6 years old, the oldest is 27. The average top-ten AutoCAD feature is over 20 years old. What does that tell you?

Programmers, have your say

Autodesk wants your input in its annual API survey. What used to be a closed survey for Autodesk Developer Network (ADN) members has been open to all for the last couple of years, and if you do any Autodesk-based development at all I encourage you to take part. Yes, that includes those of us who do most of our development in LISP. In fact, I am especially keen to see LISP developers adequately represented in this survey.

This is a one-page survey and it doesn’t take long. The full list of API surveys is on Kean Walmsley’s Through the Interface blog. Most of you would be interested in the AutoCAD survey, so here’s a direct link to that.

Kean assures us that our feedback will not fall on deaf ears, although I have yet to see any evidence of that in terms of any change to Autodesk’s decade-long policy of total LISP neglect. I guess many of us gave up hope of any improvement years ago and can’t be bothered providing feedback any more. Please don’t give up. Fill in the survey and let Autodesk know you still exist.

50 years of LISP

It is difficult to find an exact date for LISP’s birthday. It wasn’t so much born in an instant as it was gradually dragged out of the primordial slime during the heady days of late 50s computer research. What is known is that John McCarthy, LISP’s “father”, published a report in October 1958 about his new programming language aimed at providing artificial intelligence capabilities on the IBM 704 mainframe computer. That report, one of a series, was the first one to use the name LISP.

OOPSLA, a major annual conference on object-oriented programming, has decided to celebrate LISP’s 50th birthday on 20 October 2008. Practically everyone at that event is likely to be smarter, geekier and possibly even more pedantic than me. So for now I’m going to go with that date and raise a glass to LISP and John McCarthy in one week’s time.

John Walker’s almost-accidental but still inspired decision to add LISP to AutoCAD was, in my opinion, the most significant feature addition in AutoCAD’s history. There were many other feature additions without which AutoCAD would be a joke (e.g. blocks, undo/redo, dimensioning, polylines) but they were always going to happen anyway.

Adding LISP wasn’t like that. It wasn’t inevitable. It was an excellent example of Walker thinking outside the box, and it was the one thing that raised AutoCAD significantly above its competitors (yes, it had serious competitors once) at a time when the PC CAD market was still up for grabs.

The genius of this move was that instead of attempting to fill AutoCAD’s many feature holes, Autodesk could provide the tools that would let the users do that for themselves. The language was an ideal fit for a number of reasons, and users in droves started hole-filling with a vengeance. Without that boost to AutoCAD’s open architecture, the PC CAD market would have been a very different place. Autodesk itself may not even have survived into the 1990s, and I could have been writing this blog about Versacad, Computervision, or some other competitor.

Today, despite an unfortunate history of long periods of neglect from Autodesk, LISP remains the language of choice for most of my AutoCAD-related programming needs. There are exceptions, but I’ll usually first see if a given job can be done in LISP. If it can’t be done easily and well in LISP, then I will consider using one of the other available languages. For the sort of work I usually do, that doesn’t happen very often.

Why? I’ll explain my reasoning in a later post.

What is loaded at AutoCAD startup, and when?

Warning, CAD nerd stuff ahead. This is a long and technical post and if you’re using AutoCAD in a largely out-of-the-box state you probably won’t care about any of it.

If your modification of AutoCAD extends beyond the trivial, you may find it useful to know what AutoCAD loads, and in what order things are loaded. It is possible for LISP files in particular to tread on each other’s toes, so knowing what gets loaded when can be useful information for diagnosing such clashes. This post aims to provide that information. It uses AutoCAD 2009 as an example, but the same principles apply to all releases from AutoCAD 2006 onwards.

On startup, the first things AutoCAD loads are its CUI files. It first loads the Enterprise CUI file, then the Main CUI file, then any partial CUI files attached to the Main, then any partial CUI files attached to the Enterprise. I have no idea of the reasoning behind this slightly strange order, but there it is. The order of the partial CUIs loaded in each case is determined by the order in which they appear in the parent CUI files, which is determined by the order in which you attached them. If you don’t like this order, you can attach and reattach them in the CUI interface, or you can do the same thing much quicker with a text editor if you feel confident enough. If there are LISP files associated with these CUI files, they are not loaded yet. You’ll need to wait a few paragraphs for that.

Next, if you have created a file called acad.rx in AutoCAD’s search path, any ARX files listed in that file will be loaded. There are other ways in which developers can load their ARX files at startup, but I won’t go into that here.

Following that, the acad*.lsp files are loaded. First, Autodesk’s acad2009.lsp file is loaded. Next, if you have created a file called acad.lsp, that is loaded. These two files are only loaded at first startup, unless the ACADLSPASDOC system variable is set to 1, in which case the acad.lsp file is reloaded with each new drawing. Next comes Autodesk’s acad2009doc.lsp and any acaddoc.lsp file you may have created, in that order. These two files are loaded at startup and with every new drawing session.

It’s worth pointing out here that the acad200x.lsp and acaddoc200x.lsp files are Autodesk’s and are not intended to be modified by users. You can modify them, and adding things in there works fine, but updates and hotfixes can overwrite these files, leaving you to patch things up again afterwards. The acad.lsp and acaddoc.lsp files are yours, and that is where you are best advised to put your additions.

I hesitate to mention VBA because I have long avoided that development environment and my knowledge in that area is very limited, but if you’re a VBA developer and have created an acad.dvb file in AutoCAD’s search path, it gets loaded at this point.

Once the acad*.* files are loaded, then come any LISP files associated with the CUI files that were loaded at the beginning. For each CUI file, if there is a *.mnl file of the same name, that will be loaded first (*.mnl files are just *.lsp files renamed). After that, any LISP files that are specified in the CUI file will be loaded, in the order in which they appear in the CUI file itself. This order can be modified in the same ways that the partial CUI loading sequence can be modified; “delete” and “load” (detach and attach, really) the files within the CUI interface, or hack the CUI file with a text editor.

The CUI-associated LISP files are loaded as described in the above paragraph for each CUI file in turn, in the same order as the CUI files themselves: Enterprise, then Main, then partials to Main, then partials to Enterprise.

The Appload command provides a Startup Suite facility, where you can specify any number of files to load (*.arx, *.lsp, *.dvb, *.dbx, *.vlx or *.fas). If you have done so, those files are loaded at this point, in the order in which they appear in the Startup Suite list.

That’s all the actual loading done, but we’re not finished yet. At this point AutoCAD’s environment should be all ready to do pretty much anything, including things that modify the drawing database, including invoking commands. This was not true earlier on, so if you want to do things like change the drawing or run commands, this should be done using a startup routine rather than called directly at load time from any of the files loaded above.

If you’ve defined a VBA sub called AcadStartup(), it will be called now. If starting a new drawing, any sub called AcadDocument_Activate() will be called instead. The caveat about my VBA ignorance still applies here.

If a LISP function called (S::STARTUP) has been defined, it will be called next. Where could that be defined? Anywhere in any of the LISP files mentioned above, or in any LISP or other files that are loaded by any of those files, or by any files that are loaded by any of those files, and so on ad infinitum. It could even be defined in one of the ARX files loaded at any point. This would be unusual, but is quite possible.

If there are multiple (S::STARTUP) functions defined in various places, which one wins? Whichever one loaded last. That’s why the load order can be important, but it’s also why you should never have an unconditional (defun S::STARTUP …) definition in your LISP code. Instead, you should append your startup code to any existing (S::STARTUP) function. That way, your startup can cooperate with any others in your environment rather than walking all over it. If there is some interest in that subject, I can cover it in more detail in a future post.

In summary, here is the AutoCAD startup sequence:

A. CUI files loaded:
1. Enterprise
2. Main
3. Partials to Main
4. Partials to Enterprise

B. acad*.* files loaded:
1. Files listed in acad.rx
2. acad2009.lsp
3. acad.lsp
4. acad2009doc.lsp
5. acaddoc.lsp
6. acad.dvb

C. CUI-associated MNL and LSP files loaded:
1. Enterprise named MNL
2. Enterprise loaded LSP and MNL
3. Main named MNL
4. Main loaded LSP and MNL
5. Partials to Main named MNLs
6. Partials to Main loaded LSPs and MNLs
7. Partials to Enterprise named MNLs
8. Partials to Enterprise loaded LSPs and MNLs

D. Startup suite files loaded

E. Startup routines run:
1. AcadStartup() called (AutoCAD startup)
2. AcadDocument_Activate() called (Drawing startup)
3. (S::STARTUP) called

Do you do any AutoCAD development?

Yes, that includes hacking about (or producing beautifully elegant code) in LISP. If so, you may wish to go here and fill in the appropriate API survey, which is probably the AutoCAD one.

This year, Autodesk is opening up this survey, which used to be confined to Autodesk Developer Network members. I approve. ADN represents a tiny (but important) minority of fee-paying developers approved by Autodesk. I expect the results will be rather different if a significant number of “normal” AutoCAD developers notice this survey and fill it in.

If you are, say, a LISP or VBA user and are feeling neglected, please go and have your say while you have the chance. The survey closes on 1 May.

Wiki for AutoLISP

Greg Robinson, who I had the pleasure of meeting at Autodesk some 11 years ago in the run-up to Release 14, has started a Wiki for AutoLISP and other AutoCAD-based source code. I’m a big fan of LISP in AutoCAD, so I’m happy to see this resource available for users.

It’s in its infancy right now, but if you pick the All Pages link you’ll see that there already dozens of routines available, one of which may help you with something you need to do. Here’s the link to the main page:

http://lispwiki.com/