If you are familiar with customizing AutoCAD, you are probably aware of the user defined lisp files “Acad.lsp” and “AcadDoc.lsp”. The former loads one time per session at startup, and the latter loads each time a document is loaded (presuming ACADLSPASDOC=0). You can use these files to load other lisp files, set system variables, load raw lisp code into memory, and more.
BricsCAD uses a similar system, except that the files are named differently. The file that loads once per session in BricsCAD is named “on_start.lsp” and the file that loads each time a document is loaded is named “on_doc_load.lsp“. Menu lisp files (.mnl extension) are loaded whenever a menu file with the same name is loaded. So if you have a custom menu named “mycustom.cui”, then if you have a file named “mycustom.mnl”, it will be loaded also. We were able to take our AutoCAD based startup files and move them to BricsCAD with no problem.
The S::Startup function is also supported in BricsCAD. You can define (or add code to) this function, which is executed after the drawing has finished initializing. This is a safe way to call things such as the (command) function.
You can also use the BricsCAD Appload dialog (shown below) to store a list of lisp/BRX/VBA/NET files that can be loaded at startup. Note that this is per-user, per-profile. Lastly, the Registry-based DemandLoad mechanism has been extended to support Lisp and VBA files.
See this page for more information.
Just a minor addition related to APPLOAD, which uses “appload.dfs” :
that file is searched by normal findFile() mechanism, based on support search pathes.
So it is possible to have 1 single global “appload.dfs” for all users and all profiles, when “appload.dfs” is located in a particular folder, and that folder is defined as first support search path.
Thanks for that info Torsten.
You can also have multiple S::Startup definitions. BricsCAD will happily run S::Startup functions contained in on_start.lsp, on_doc_load.lsp, mycustomcui.mnl
Thanks for the info Jason!