Automatic LISP Loading

There are a myriad of ways to load AutoLISP applications in AutoCAD, including acaddoc.lsp, an .mnl file, the Startup Suite, and manually by various means. For application developers wishing to deploy their applications to others, all of these methods have drawbacks. The ideal solution should be easy to implement in an installation program, require minimal or zero changes to the user’s AutoCAD configuration, work the same way across all versions of AutoCAD, and easily undone when the application is uninstalled.

ObjectARX application developers have long used registry demand loading to load their applications automatically, either when AutoCAD starts or when the user enters a command that the application defines. Registry demand loading is relatively easy to set up and meets the other requirements for an ideal solution, except for one problem: it works only with ObjectARX modules (or with .NET modules in AutoCAD 2006 and later).

Many years ago, I created a solution to this problem by building a small stub ObjectARX module that did nothing but load an associated LISP file. This effectively allows the registry demand loading mechanism to be used for loading a LISP file. If you develop AutoLISP applications that could benefit from registry demand loading, then I have a Christmas present for you: contains a complete suite of newly updated stub modules for all versions of AutoCAD from AutoCAD 2000 to AutoCAD 2010, plus modules for Bricscad 9 and 10, which also supports registry demand loading.

To use the stub modules, just rename them so that the base filename matches your application’s main LISP filename, then install them in the same folder as the LISP file and create the registry demand load entries. The only work you have to do is to get the stub module to load. You can simply drag and drop the appropriate stub module into a running instance of AutoCAD in order to test it.

[Update 2014-02-18: See Building a commercial grade lisp plugin installer in 5 easy steps for a solution to setting up the demand load keys using Inno Setup.]

Creating the demand loading registry keys is not difficult, but it may require some programming. I write custom actions for my installation programs that enumerate all installed AutoCAD versions and flavors, and set up the demand load keys for every one. However you do it, the final result should look something like this (for AutoCAD 2010 on my system):

In this screen shot, I created an application called “!LspLoadTest” (the “!” was added just so it displayed at the beginning of the list). I added the minimum required subkeys. The LOADER string value is set to the complete path of the stub module, and LOADCTRLS is set to a value of 2, which means I want the application loaded when AutoCAD starts. LOADCTRLS is a bit coded value; for use with LspLoad, it’s only useful values are 2 or 4. A value of 4 means “load when my command is invoked”; this mode requires a COMMANDS subkey that lists the defined commands.

The way it works is very simple. In the example above, you can see that I renamed the module (but left the “.18.x64.arx” so that I can tell it apart). I then added !LspLoadTest.lsp to the W:LspLoad folder. That file contained the following:

(princ “nThis test file loaded from “)
(princ (if GetPathOf!LspLoadTest (GetPathOf!LspLoadTest) “<unknown>”))

Now when I start AutoCAD 2010, I see on the command line:

This test file loaded from W:\LspLoad

These files are free to use for any purpose. Have a great holiday, everyone!

11 thoughts on “Automatic LISP Loading”

  1. Hi Owen, very interesting post.
    I’m developing .dll applications. The installer, in addition to put the files in C:program filesmyAppFolder, makes the necessary registry changes in order to allow user demand loading of myApp.dll. My trouble is to tell AutoCAD to perform automatic loading of myPartialCUI.cuix file at every next startup after installation.

    What are the ways to do this task?

    Thank you & regards


    1. One way is to create another DLL whose job it is to load the partial CUI if needed, then set that DLL to load at startup. You’ll have to jump through some hoops from the DLL’s IExtensionApplication::Initialize() function to send a command to the editor, then handle the CUI loading within the command handler. Blog comments are not a good medium for this discussion; an actual discussion forum would be more appropriate

      1. Thank-you Owen for the kind answer.
        I wrote here cause I did not know where else to do it.
        The way you suggested is the same that I’m using, so I’m really happy with this.


  2. Hi Owen, a question, is there a web address where you can get the key products used autocad and bricscad, example autocad 2007 uses: ACAD-5001: 409, the problem is that using inno setup to create the installer program and would like to add the key once to load the application! thanks for the help!!

    1. You really don’t want to hard-code those registry keys into your installer, as there are hundreds of possibilities. You need to either (A) iterate over each one at install-time and install your application in all instances; or (B) provide a list and allow the user to choose which instances to install for; or (C) use the CurVer value of the parent key to choose the “current” subkey, and install only there.

      1. the solution is: pascal know, I do not know, I look like adding loadctrls and load different versions of autocad and bricscad to achieve load my application. thanks

  3. Hi, I read the source code you shareed, but I can’t understand well.
    In my opinion there is no need to use AcRx::kLoadDwgMsg and AcRx::kInvkSubrMsg; Why not put “vl-load-all” in “AcRx::kInitAppMsg “, load lsp file when app start.
    I send you an email…but no answer.

    sorry to trouble you. thank you alot.

    1. Executing lisp code at kInitAppMsg is unsafe, because lisp requires a document context, and kInitAppMsg can occur before there is a document available. On the other hand, kLoadDwgMsg occurs only when there is a document context available.

Leave a Reply

Your email address will not be published. Required fields are marked *