TIPniques: Look, Ma! No Command Line
The longer I program, the more I learn. When I was just learning to program, my code was really unorganized and not very versatile. I would have several functions with the same general purpose, but desire slightly different results. I have learned quite a few helpful tips over the years that I would like to share with you. Let's take our AutoLISP programming to the next level.
AutoCAD is similar to your home—the better your house cleaning, the smoother your time spent there.Remembering to clean up is very important. AutoLISP is more forgiving than other programming languages, but you should be just as diligent in clearing your variables. If you open something, be sure to close it or clear it. Our computers are getting faster and faster, but the programs we write do not need to bloat our machines. When you use setq, AutoCAD will keep that in memory until AutoCAD is closed or, even better, when we release it from memory. Small variables won't hinder your computer much, but it’s a good habit to clear them anyway. Then when using larger objects, you won't forget to clear them out. An easy way to clear out your variables is to add them to the commands parameter list:
(defun c:RunMe ( / Var1 Var2)
Here, we are defining a command line function and letting AutoCAD know that we need to clear Var1 and Var2 from memory when the command has successfully finished running.
Cut Out The Command Line
It is easy to use what we are familiar with, but we should only use it as a starting point. Many long-time drafters and designers already know how a command works. If not, we can quickly “dry run” the command to see the steps needed. Then it is pretty easy to copy and paste it from the command line and use it in our AutoLISP routine. While easy, it isn’t a good idea for creating a function that can be used in several situations. Instead, we should use AutoLISP functions. Using command line functions in an AutoLISP program is not ideal—it is slower and limited. While you can string together some commands from the command line and use it in LISP, that type of coding is better suited for creating scripts. It will run, but not nearly as fast and will not be as versatile. You lose some great functionality when you start adding command line calls to your program.
Break your code into smaller functions that you can use in other programs. Creating functions helpsyou in a few ways. It breaks your code up for easier reading, it allows for easier error trapping, and it allows you to use portions of your code multiple times in the same program or in different programs. After working in several design industries, I have learned that I re-use a lot of codeand particularly small functions. It may be quicker and use fewer lines of code to change the color of an object using text copied from the command line. However, your code will be more versatile if you use function in your command. Below is a function that will change the color of an object. You provide the function with the document you are looking in, the object to change, and the new color of that object. Having the document parameter allows us to call this function in command that opens only the database portion of the drawing. This could be a drawing that is not currently opened in your editor.
The next command calls the function from above. It has some error checking to ensure our function will run properly.Another helpful tip is to prevent errors. If you only want an integer, use AutoLISP to your advantage and use GETINT. Using that function the user can only enter an integer. In the following code, when asking for a color we only want integer, so we use GETINT. I have also wrapped that in a while check to keep prompting, which will prevent the user from hitting enter and not supplying an integer. In our selection set we allow only lines and polylines. Again we use a while check to ensure that the user selects the correct objects. After we know the user has either cancelled the command or entered an integer and grabbed some valid lines, we will continue with the command and run our function.
We can also call that function in another command and have it change all lines and polylines in the drawing.
With the COLORLINE function we can also use it in a reactor. A reactor will watch the opened drawing and when something happens, our reactor is notified and we react based upon what it tells us. That “something” could be many things. It could be that a command has started or an object has been erased or exploded. Reactors can be extremely useful when trying to maintain drafting standards and ease drafting. There are many types of reactors available to you in Visual LISP.
We also have the ability in AutoLISP to modify drawings without opening them on the screen. This process is done using ObjectDBX. An AutoCAD drawing, in its most basic form, is a database. Through AutoLISP we can access and modify the information in the database. There is a noticeable increase in speed when modifying drawings using ObjectDBX. The main reason for the speed increase is there are no graphics for your computer to process. There are a few limitations in ObjectDBX—you cannot use command line functions or do anything that requires user interface with AutoCAD. For example, you cannot have a user manually select the lines you want to change, but you can have the program select and modify those lines for you. Being able to modify hundreds of drawings at a time is great, but you should always test your code on some sample files first.
Hopefully these tips will help you create robust commands that are built on a toolbox of functions—functions versatile enough to handle several situations and uses.