For BricsCAD in India, contact: rakesh.rao(at)thedesignsense.com
+91-9243438300 / +91-8073279755
In our last post we talked about automatically loading a standardized profile at BricsCAD® startup so all users would see the same CUI interface and have the same configuration folders for external files and peripherals like printers/plotters. And while this is certainly a good start to achieving overall consistency, there are other issues that can come into play – particularly if you are migrating users from other CAD systems to BricsCAD.
When users have worked with another CAD system for many years their entire base of experience is based on the command vocabulary and function of that other system. And, as we all know from our own experiences, change can be hard. So it turns out that making BricsCAD function as much like the old system our users already know is a great way to improve user satisfaction, raise productivity, and shorten training times for our BricsCAD implementation.
In this installment we’ll explore how you can use some LISP code to tailor BricsCAD to your users’ liking while achieving a standardized environment that is easy to maintain over time. Let’s see how.
The Concept
If you are implementing BricsCAD for users migrating from a popular system like AutoCAD®, it is desirable to make the BricsCAD command vocabulary as compatible with it as possible and LISP is a great way to accomplish this task. But before we dive into any code let’s outline the concept of what we’ll be doing:
Standardize loading. Here we’ll use the ON_START.LSP file to control the BricsCAD startup.
Standardize the LISP environment in a network folder. Here we’ll establish a standardized network location that contains any LISP files and resources our users will need (while also applying protective permissions to discourage tampering).
Standardize the command vocabulary. Here we’ll use some LISP to make BricsCAD’s command set feel like users expect from their old CAD system.
Add useful functions. Here we can use LISP to add useful functions like keystroke shortcuts for additional productivity.
The true beauty of this approach is that any custom code you create will be in a single network location that serves all while making maintenance easy for you.
Be sure ON_START.LSP Exists
When BricsCAD starts up it automatically looks for an AutoLISP file called ON_START.LSP and executes any code it finds in the file, so you need to be sure it exists and that BricsCAD can find it. All you must do is place the ON_START.LSP file in BricsCAD’s support directory – you can manage this using the SETTINGS command and looking under Program Options / Files.
Now simply exit BricsCAD and restart and the ON_START.LSP file will be loaded in and executed.
Add Code for Network Location
In the ON_START.LSP place code that will instruct BricsCAD where it should load all your custom code. For the sake of argument, we’ll say that the file we should use is as follows:
X:\LISP\STANDARDS.LSP
This code would now be placed in the ON_START.LSP file:
(if (findfile "x:\\lisp\\standards.lsp") (load "x:\\lisp\\standards.lsp") ) (prompt “\nBricsCAD startup routine loaded.”)
This code has several advantages:
- It tests for the presence of the network file and only loads the file if it is found – thus preventing errors for unplugged laptop users where the network directory can’t be found.
- A diagnostic prompt is issued so a quick inspection of the command line will show if the ON_START.LSP file has been loaded.
- Using this methodology, the ON_START.LSP file will never need to be edited again so long as the X:\LISP\STANDARDS.LSP file is maintained.
Now save the ON_START.LSP file, restart BricsCAD and make sure the file loads by looking for the BricsCAD startup routine loaded message at the command line.
Create the STANDARDS.LSP File to Define Commands and Shortcuts
Now it is time to create the X:\LISP\STANDARDS.LSP file and put some code in it. But what code is that? Consider these practical examples:
Example 1:
Several prior AutoCAD® users noticed that BricsCAD doesn’t have an ORBIT command but does have a command called RTROT that works in much the same manner. These users are very used to typing in ORBIT and have even created some CUI based macros they wish to use so not having an ORBIT command is a pain.
How can we make these users happy? We give them an ORBIT command by putting the following code in the X:\LISP\STANDARDS.LSP file:
(defun C:ORBIT () (command “RTROT”) (princ) )
This code does the following:
- It defines a command function called ORBIT that invokes the BricsCAD RTROT command. This function can be used at the command line or within macros as needed.
- It provides the AutoCAD® user with a command environment that feels comfortable to them. They simply think they are using the ORBIT command.
- Since the code is in the centrally located STANDARDS.LSP file all users will also see the new ORBIT function.
After the next startup of BricsCAD your users will be able to type ORBIT as if it was a native BricsCAD command.
Example 2:
A prior AutoCAD® user has noticed that BricsCAD’s LAYER command brings up the unified Drawing Settings panel rather than a simple list of layers as they are used to. Since the Drawing Settings can’t be used transparently like the AutoCAD® user is used to it causes them some confusion. However, the BricsCAD command LAYERSPANELOPEN works just like the layer command in AutoCAD® does.
How can we make this user happy? We redefine the LAYER command to act like AutoCAD®.
This code would now be placed in the STANDARDS.LSP file:
(command “undefine” “layer”) (defun C:LAYER () (command “LAYERSPANELOPEN”) (princ) )
This code does the following:
- It undefines the LAYER command as BricsCAD knows it.
- It substitutes a new LAYER command into the BricsCAD command vocabulary.
- When LAYER is entered the LAYERSPANELOPEN command is invoked.
Now the AutoCAD® user feels right at home and never needs to know the LAYERSPANELOPEN command even exists.
Example 3:
A user said their last CAD system had an NP command that brings up Notepad for quick file editing.
How can we make this user happy? We simply add an NP command to BricsCAD that calls the standard Windows Notepad.exe file.
This code would now be placed in the STANDARDS.LSP file:
(defun c:np () (startapp “notepad.exe”) (princ) )
The only thing to mention in this example is use of the STARTAPP function which allows the calling of external programs from LISP routines.
Note: No path is required in this case because NOTEPAD.EXE is a system level command that Windows already has registered.
The Sky is the Limit
How much do you care to do with your STANDARDS.LSP file? Only you can answer that question but at least you know how the approach works now and can start exploring what you’d like to do.
Now that we’ve installed BricsCAD, gotten the correct configuration and profile information in place and now have the command vocabulary set to emulate other programs we should be able to move forward with training. And that’s exactly the topic we’ll start covering next week.
Ready to try BricsCAD?
Easy to try, easy to buy, easy to own. That’s BricsCAD. Try all of our products, for free for 30 days at www.bricsys.com. Freedom of choice, plus perpetual (permanent) product licenses that work with all languages, in all places. You’ll love what we’ve built for you with the BricsCAD V19 product family.
More CAD Managers’ Corner Stories
- Network Installation Mechanics – Part 1
- Network Installation Mechanics – Part 2
- LISP Concepts for Easy Migration
- Minimum Training for Maximum Learning– Part 1
- Minimum Training for Maximum Learning – Part 2
- Three Steps to BricsCAD Adoption
- Preparing for Implementation – Part 1
- Preparing for Implementation – Part 2
- Preparing for Implementation – The Proving Ground
Comments