Automatic LISP + VBA Loading

There are several ways to automatically load Lisp, VBA and BRX/NET files, mostly compatible with similar functionality found in other CAD systems.

The most-often used and well-known mechanisms :

for Lisp modules :

• using "on_start.lsp" :application-provided Lisp file, automatically loaded at BricsCAD startup (and for each drawing opened, if ACADLSPASDOC=1 is configured)
• using "on_doc_load.lsp", also application-provided Lisp file, automatically loaded with each drawing opened or created
• MenuLisp file(s) "*.mnl" : for each menu (mnu/mns/cui) attached to BricsCAD, a same-named MenuLisp file <menuname>.mnl is searched in the folder of the menu itself - and if the .mnl file is present, it is loaded as well, for each opened or created drawing

for BRX/NET modules :

• using "autoload.rx" : application-provided text file, naming the modules to be loaded as a plain line-by-line list (with or without path - in latter case the files are searched the normal way, using defined SupportPathes)
• using Registry-based DemandLoad mechanism - this is compatible with similar ARX mechanism, and available for BRX and BRX/.NET modules only

for VBA modules :

• no particular mechanism to automatically load VBA files is available - only suitable way is to use Lisp code to load desired VBA files, using (vl-vbaload) or (command ...) functions

Since V17: Registry-based DemandLoad + Appload's "AutoLoad"

With BricsCAD V17, there are 2 more mechanisms to automatically load Lisp, VBA and BRX/NET modules during startup and per-drawing (respectively), and on command invocation.

The Appload Dialog has been redesigned, and offers an "AutoLoad" feature, to load designated Lisp, VBA, BRX/NET modules during startup (and in case of Lisp programs, for each drawing opened/created).
Informations are stored in "appload.dfs" file (searched for in SupportPaths), and the associated "AutoLoad" status for each file is stored in Registry, under current profile.
This means, Appload Dialog mechanism is per-profile and per-user.

For more details, please see topic Appload Dialog.

Additionally, the Registry-based DemandLoad mechanism has been extended to support Lisp and VBA files as well.
Now it is possible, to define DemandLoad/Registry-based loading of Lisp and VBA application files, on BricsCAD startup and for each drawing opened/created, as well as Lisp/VBA application code loading, based on entering a command by user (or from other application code).

For more details, please see topic Registry DemandLoad.

Important hint for all AutoLoad mechanisms

There is a BricsCAD-specific Lisp function (vl-list-loaded-lisp), which can help Lisp developers and applications, to work independent on SupportPaths setting.
After an application's LISP file was loaded, by any of the mentioned mechanisms, (vl-list-loaded-lisp) returns a list of loaded Lisp files, and the Lisp files are specified with their full path included  - the application can check for an "magic" file there, and extract the folder of that "magic" Lisp file
=> hence, a Lisp application can dynamically determine its "home / installation folder" at runtime, and assign that path to a global variable.

example :
assume, the application's home folder is assigned to a variable $HomeFolder_MyApp; later on, any loading of Lisp, DCL, VBA files might use that home folder variable always :
(setq MyAppFile1 (findfile (strcat $HomeFolder_MyApp "MyLisp1.lsp")))
(if MyAppFile1 (load MyAppFile1)) (alert "* Installation Error"))

This way, a Lisp application can work entirely without any dependency on SupportPaths.