Migrating an established AutoCAD-style LISP set into BricsCAD is rarely about whether it runs. It is about when, where, and how it loads, and how you package it for repeatable rollout across teams, offices, and versions. This BricsCAD LISP migration guide covers startup files, compatibility, and best practices for CAD managers who need clear load order, clean search paths, secure loading, and fewer it works on my machine surprises.
If your current setup uses a Startup Suite, many support paths, network toolsets, and a mix of AutoLISP and Visual LISP, you can migrate well. The key is to treat BricsCAD startup LISP as part of the environment, not as a pile of loose .lsp files.
Before you migrate LISP to BricsCAD, capture what you have now:
This inventory becomes your check list. It also helps you spot where autolisp bricscad compatibility issues are most likely to appear.
Companies often miss how many AutoCAD environment file types are involved in a LISP deployment. A successful move knows that LISP is only one part of the stack.
Common file types you may have today:
Recognising these file types helps you move custom commands to BricsCAD without chasing missing resource errors that look like LISP faults but are not.
BricsCAD LISP support is strong for normal production automation:
For most teams, most routines will run after you fix load order, paths, and dependencies.
The friction points usually fall into these buckets:
Treat autolisp bricscad compatibility as a test programme, not a guess.
If you rely on Visual LISP features, especially COM automation, validate them early. Many corporate toolsets depend on (vl-load-com) and vla-* calls for layer work, xrefs, plotting, title block attributes, and more. Plan a COM-heavy pilot set first.
A reliable migration needs a disciplined BricsCAD startup LISP plan. You want:
BricsCAD gives you two startup hooks that map well to enterprise deployment:
ACADLSPASDOC is 0. Use it for:
Use ON_DOC_LOAD.LSP as the primary loader for libraries and command definitions, because it loads unconditionally for every drawing opened or created, independently of ACADLSPASDOC. Octaves’ own customisation guidance states that on_doc_load.lsp is the better of the two for launching your programs. Reserve ON_START.LSP for the small amount of work that only needs to happen once per session, and set ACADLSPASDOC to 1 if you want the on_start files to run per drawing as well.
Make sure your rollout notes cover both files, plus naming and case rules, so helpdesk staff can diagnose issues fast. Note also that BricsCAD ships two reserved files of its own, on_start_default.lsp and on_doc_load_default.lsp, which load before your equivalents. Octave advises against editing them, because the user file manager can replace them with newer copies from the installation’s UserDataCache folder after an update. Always put your own code in on_start.lsp and on_doc_load.lsp.
The real question is how to keep file locations stable, supportable, and findable. BricsCAD locates startup and support files through the support file search path held in the SRCHPATH system variable, whose default first entry on Windows is C:\Users%username%\AppData\Roaming\Bricsys\BricsCAD\V26x64\en_US\Support, reachable with the SUPPORTFOLDER command. The startup files do not have to live in that folder. They only need to be found somewhere along that path, which you can confirm in one line with (findfile “on_doc_load.lsp”).
A practical enterprise layout looks like this:
Recommended code layout:
This layout makes it easier to troubleshoot fix LISP not loading BricsCAD cases because you can see whether the bootstrap failed, the library failed, or one module failed.
There are several ways to load LISP automatically in BricsCAD. In corporate settings, prefer stable methods over ad-hoc ones.
Your ON_START.LSP should do the minimum:
Keep document setup separate so you avoid slow startup and no-active-document errors.
BricsCAD has no Startup Suite. The equivalent is the AutoLoad column in the APPLOAD dialog, backed by an appload.dfs text file and per-user, per-profile registry entries under HKEY_CURRENT_USER. Keep the list limited to bootstrap files, not dozens of modules. Load order is not random: the dialog’s Up and Down arrows set the sequence, and LISP files are always loaded after BRX, .NET and VBA modules, because those load globally and often define interface functions for LISP. Because appload.dfs is located through the normal support path search, putting one copy in the first support folder lets a single file serve all users and profiles. Too many entries still:
You still need an escape hatch for support work:
A good migration plan uses A and B in production, C only when needed, and D for support. Be aware that BricsCAD documents three further automatic loading mechanisms you will meet in third party products. Menu LISP: a same-named .mnl file in the folder of a loaded menu is loaded for each drawing. Registry based DemandLoad: keys under Software\Bricsys\BricsCAD\version\language\Applications load a LISP file either for every drawing (LoadCtrls 2) or on invocation of a declared command (LoadCtrls 4). Plug-in bundles: from V26.2, .bundle packages containing BRX, .NET or LISP content are parsed from a manifest by the bundle loader, controlled by the APPAUTOLOAD system variable and the APPAUTOLOADER command.
This is a pattern, not a copy-paste universal answer. Adjust it to your standards and security model.
Key rules:
Good startup logic should:
Also think about:
These are basic best practices for LISP deployment in managed CAD environments.
Deployment hygiene is where many LISP migrations fail. The code is not always wrong. More often the loader never ran, or the file was not on the support file search path when BricsCAD looked for it. BricsCAD’s documented loading mechanisms are path based rather than trust based, and no equivalent of AutoCAD’s SECURELOAD and trusted paths model is described in the current BricsCAD help. Treat trusted location as an organisational policy you enforce through share permissions and a release process, not as a product feature that will block a findable file from loading.
In a corporate rollout:
If users say routines do nothing, or load on and off, treat it as a security or path issue first. Most fix LISP not loading BricsCAD cases come down to:
When you migrate AutoCAD LISP to BricsCAD, work through these items in order.
Search for:
Replace them with:
If you use (command) a lot:
If your routines attach reactors on load:
For Visual LISP support in BricsCAD, test:
When behavior differs, isolate a small repeatable script before you refactor the whole toolset.
From a CAD management view, the biggest differences are practical rather than syntactic:
Thinking about these as process changes makes migration smoother than chasing one code edit after another.
Use this order:
If you log early, most not-loading tickets become 5-minute fixes.
There is no separate Visual LISP IDE in BricsCAD. The VLIDE command opens BLADE, the BricsCAD LISP Advanced Development Environment, so existing macros and documentation that call VLIDE still work. BLADE runs on Windows, Linux and macOS and provides editing, project handling, breakpoints, an inspector, a syntax and variables check, and an integrated profiler. If code behaves differently under the debugger than in production:
Keep the IDE for development if it fits your process, but do not make production depend on it being identical across tools.
A migration succeeds when you can deploy it the same way every time.
A strong rollout plan has:
For CAD managers, this is the difference between we migrated once and we can maintain it for years.
After you migrate LISP to BricsCAD, good results usually look like this:
That is the mindset behind LISP routines for BricsCAD setup as a managed system, not as a pile of files.
A successful BricsCAD LISP migration guide comes down to three priorities:
Do that well and migrate AutoCAD LISP to BricsCAD stops being a risky one-off project. It becomes a stable platform upgrade without giving up custom workflows or the gains your custom commands deliver.
Question: Where should I put ON_START.LSP and ON_DOC_LOAD.LSP, and what should go in each?
Short answer: Put ON_START.LSP in a path BricsCAD searches at launch, such as a central read-only support path or a managed local cache on the support path. Use it only for once per session work: set or check support paths, set globals and publish them with (vl-propagate), and log events. Load your core file from ON_DOC_LOAD.LSP instead, because on_start.lsp runs only for the first drawing unless ACADLSPASDOC is set to 1. Put ON_DOC_LOAD.LSP in the same managed library. It runs when a drawing opens and should handle document-scoped tasks such as reactors, on-demand modules, and per-drawing variables or standards.
Question: Our AutoCAD setup uses acad.lsp, acaddoc.lsp, and .mnl loaders. How do these map to BricsCAD?
Short answer: The mapping is a straight rename. acad.lsp becomes on_start.lsp, acaddoc.lsp becomes on_doc_load.lsp, and BricsCAD does not read the AutoCAD file names. Put the bulk of your loading in ON_DOC_LOAD.LSP, which runs for every drawing, and keep ON_START.LSP for once per session work, remembering it runs only for the first drawing unless ACADLSPASDOC is 1. Menu LISP works as it does in AutoCAD, since a .mnl file beside a loaded menu of the same name is loaded for each drawing, so keep it small and use it only to bootstrap your standard loaders. That gives you predictable order and easier support.
Question: What are the most common reasons my LISP does not load after migration, and how do I triage fast?
Short answer: Most failures are environmental, not code related. The bootstrap did not run, the library path is not on the support path, the code was placed in on_start.lsp while ACADLSPASDOC was 0 so it only loaded for the first drawing, or a needed resource was not found. Triage in this order: 1) confirm your loader runs with a banner or log, 2) run (findfile “on_doc_load.lsp”) and (findfile “yourfile.lsp”) to verify the support paths and network access, 3) run (vl-list-loaded-lisp) to see exactly which LISP files loaded and from which folders, 4) check that dependencies such as DCL and config files exist, 5) ensure shared libraries load before app modules. Use APPLOAD for targeted checks.
Question: How should we structure and deploy our LISP library for multiple offices and BricsCAD versions?
Short answer: Use one read-only central library with optional versioned subfolders, plus a managed local cache if you need speed or offline use. Keep a tiny /bootstrap, shared /lib helpers, business /apps, /ui assets, /config files, and /tests. Drive everything from one bootstrap file and one config file that maps BricsCAD versions to the right library. Package each release as one artifact with a manifest, and include a small regression suite to check updates.
Question: What should we test first if our toolset relies heavily on Visual LISP and COM?
Short answer: Run a COM-heavy pilot early. BricsCAD implements the vla-, vlax- and vlr- families through its own Fast-COM layer, which also makes them available on Linux and macOS, although not every vla- property and method is implemented on those platforms. Validate object creation, property and method names, plot and layout behavior, and any ActiveX differences, use (vlax-get-acad-object) rather than a product specific application ProgID, and consider the non-COM property functions (getPropertyValue), (setPropertyValue), (isPropertyValid), (isPropertyReadonly) and (dumpAllProperties), supported since V21, which behave consistently across all three platforms. Focus on high-value workflows such as layers, xrefs, plotting, and title block attribute automation. When behavior differs, isolate a minimal repeatable script before you refactor. Keep command automation strong by testing prompts and options and by avoiding locale-based inputs. If needed, gate features by BricsCAD major version through your bootstrap and config.
