Almost no differences
When you’re ready to start migrating, you’ll find that there are virtually no differences in BricsCAD LISP versus OtherLISP. Your code loads and runs, and the functionality is identical. The primary differences when “porting” your apps will be a few minor setup steps, command line structure, and possibly file locations. To start, let review the setup and launch of your existing programs in BricsCAD.
If you are auto-launching your programs using Acad.lsp or Acaddoc.lsp, you will simply need to rename and or combine those files into a single file named “on_start.lsp”. To enable this feature, simply toggle the option in Settings / Program options / System:
Enjoy the BricsCAD Settings Panel
I would also recommend that you prepare to spend a little time familiarizing yourself with the Options/Setting menu in BricsCAD. As you dive in, you will find a ton of settings and options you probably wish you had in your “other” CAD environment. Welcome to BricsCAD!
The next step in the settings dialog would be to add your support folders to the Files search path, which is found within Settings / Program Options / Files:
As a rule, I never hard code any paths unless absolutely necessary. The support paths I use will typically be added as in the manner above and/or located one level below the current project folder. Typically, I will use a “findfile” function to validate the file exists before proceeding with my commands, as in the method below:
(if (findfile “custom-code.lsp”) (load “custom-code”))
In fact, this is one of the methods I’ve used to demand-load my functions within the on_start.lsp file:
(defun c:my-function () ; this defines the command (if (findfile “custom-code.lsp”) ; check if the file exists (load “custom-code”) ; if True, launch (alert “Custom-code not in Support Path!”) ; not True, so alert) ) ; end If statement ) ; end function
The command defun (DEfine FUNction) is the same name as the function inside of your on_start.lsp file and that function redefines the calling function when it’s launched. This is another cool reason for using this method, as it demonstrates how dynamic LISP can be!
Take advantage of your move to BricsCAD
When your engineering workflow is running, you usually build a long list of maintenance items that you keep putting off. Migrating to a new CAD environment offers an opportunity to make some of those updates and update your documentation standards. Almost every client that I’ve helped to migrate need to address old-style hard-coded paths, 8.3 syntax filenames, old layer naming conventions and other no-nos within their standards. As we move forward in this series, I will share some of the methods I use to store user settings and defaults external to your LISP code, so that they can be updated more easily. Until next time, happy coding!