Registry DemandLoad

Registry DemandLoad for LISP and VBA applications

Registry-based DemandLoad functionality is available for ARX / BRX / .NET developers since long time, to load ARX / BRX / .NET application modules on CAD system startup, on presence of (application-specific) "custom entities", on invocation of application-defined commands and functions (and more), with flexibility and comfort.
This also allows such applications to integrate nicely into the target CAD system, from an application installer, adding dedicated Registry entries.

Since BricsCAD V17, this useful and smart mechanism is also available for Lisp and VBA applications; all usual rules as designed for BRX / .NET applications also apply to Lisp and VBA files now, Lisp/VBA specific details are automatically handled by BricsCAD, to provide a uniform and consistent logic.

Registry Keys :
to define DemandLoad support for a Lisp/VBA application, some Registry entries need to be defined (usually by application installer);

for an application named "MyApplicationName" is :

main Registry Key, under HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE		Software\Bricsys\BricsCAD\<VersionKey>\<LanguageKey>\Applications\<MyApplicationName> Note : for x86 application, running on x64 Windows, when using HKEY_LOCAL_MACHINE, the "Wow6432Node" must be respected : Software\Wow6432Node\Bricsys\BricsCAD\<VersionKey>\<LanguageKey>\Applications\<MyApplicationName> so using HKEY_CURRENT_USER is suggested
Value Keys to define application behaviour		Loader (string) = "application file name" : Lisp/VBA application file, without path, with relative or absolute path LoadCtrls (dword) = loading mode : 2 = "OnStartup" 4 = "OnCommand" Description (string) = "optional application description" : used i.e. for error messages, if loading fails
.\Commands sub-key to optionally define application-specific commands		"GlobalCmd" (string) = "LocalCmd" : allows to define a "localised" command name (optionally); both "GlobalCmd" and "LocalCmd" can be identical; multiple command name entries are supported; Commands sub-keys are only required if the "OnCommand" loading mechanism is intended

Some notes for LISP based applications

LoadCtrls :
using 2 (OnStartup) means "loading for every drawing", as loading on BricsCAD startup would likely not make much sense;

using 4 (OnCommand) requires that the Lisp application provides a Lisp command definition (defun C:GlobalCmd ...) - there is no need to define a similar (defun C:LocalCmd ...) definition;

note 1 : the C: prefix must not appear in Registry command name definitions !
note 2 : based on these Registry definitions, the BricsCAD DemandLoad mechanism automatically creates internal wrappers for the C: commands, for each opened/created drawing;
as a nice side-effect, the C:GlobalCmd and C:LocalCmd commands are also available for CommandBar's AutoComplete feature.

Some notes for VBA based applications

LoadCtrls :
using 2 (OnStartup) means "loading on BricsCAD startup", as VBA files are loaded globally (like BRX + .NET modules);

using 4 (OnCommand) requires that the VBA application provides a main function GlobalCmd - there is no need to define a LocalCmd;

note 1 : based on these Registry definitions, the BricsCAD DemandLoad mechanism automatically creates internal wrappers for the commands, for each opened/created drawing;
2 nice side-effects :
a) GlobalCmd and LocalCmd commands are also available for CommandBar's AutoComplete feature
b) normally, VBA applications can not define own commands, which are available at command line - using DemandLoad mechanism this is now possible (based on those automatically created command wrappers)

Please see these images for the above-mentioned Registry keys :


	LISP application : main registry entries, defining the module's properties (using OnCommand loading)

	LISP application : "Command" registry entries, defining the Lisp commands

	VBA application : main registry entries, defining the module's properties (using OnCommand loading)

	VBA application : "Command" registry entries, defining the VBA commands