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, asame-named MenuLisp file <menuname>.mnlis 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)

usingRegistry-based DemandLoadmechanism - 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.

TheAppload
Dialoghas 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 Dialogmechanism is
per-profile and per-user.

Additionally, theRegistry-based DemandLoadmechanism 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).

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.