Visual LISP: Hunting Down Problems - Part 1

 By Bill Kramer

One winter day in the 1970s—when I was an undergraduate in Computer Science at Northwestern University—I was thrilled to use an "automatic" card sorter to reorder several boxes of 80-column punch cards I'd dropped in the snow. Now that was automation. A task I thought would take days, took merely an hour.

Twenty-five years later the tools available to programmers have improved by several orders of magnitude, and today we enjoy such things as integrated development environments (IDEs) for the entry and testing of programs. The reason is simple: programmers have been writing tools for programmers.

At Autodesk University® 2001 I had the pleasure of meeting many AutoLISP® programmers. To my surprise many of them had yet to explore the nature of the Visual LISP IDE, which is why I chose to start this series with a look at various aspects of this powerful programming tool.

In this article, I will set the stage with a quick introduction to the applications development sequence. That will lead into a discussion of the mode or state of a program from a programmer's perspective. From there I will introduce the most powerful debugging tools in the Visual LISP IDE, Breakpoints and Watches.

Application Development

The creation of an application involves four primary steps: analysis, design, programming, and testing. During analysis, you write down the concepts and ideas you want to turn into an application. This highly creative stage involves both the programmer and the end user with the end user driving the majority of the process. The output of the analysis is a rough plan for the application.

Design is the process of refining these ideas into a logical structure. The programmer is deeply involved in the design as this is when the ideas are converted into modules and algorithms. The output of the design is a series of user interface descriptions such as dialog boxes along with a logical flow description of the program and processes involved. Once the user approves the output of the design, the programming and initial testing stages can start.

At this point the programmer is entirely in charge of the conversion of the design into a working application. It's also when the IDE (integrated development environment) of the programming language of choice, with its set of debugging tools, can make the programmer's job easier. These integrated tools won't reveal themselves with just some casual poking around in the program. You're going to have to learn a few basic IDE concepts and the means of manipulating them.

Program Modes

These concepts are essentially the same for all of the IDE choices you have in Autodesk products, which include Visual LISP™ and Visual Basic for Applications (VBA) inside AutoCAD® and AutoCAD-based products such as Autodesk® Land Desktop Mechanical Desktop® and VBA for Autodesk Inventor™ software.

During application development a program exists in one of two modes (states or conditions). When you are directly typing or editing the code, or laying out a dialog box design, the program is considered to be in design mode. For expediency's sake, let's call the other mode run mode, which is that time when you are executing the program or portions of the program for testing purposes.

Depending on which mode you are in, different tools are available to you at different times. You need to recognize which mode you're in to choose intelligently among the tools. (You should also spend some time with the online Help and other resources available to you.) For example, Figure 1 shows the Debug toolbar in design mode (most of the icons are off) and Figure 2 shows it in run mode (all icons are on).

You will spend most of your time with the program under development in design mode. Typing and editing code should consume the majority of a programmer's time for a well-designed application. You'll be in run mode more toward the end of the programming phase as the application modules start to come together.

One question you most likely have at this point is how to transition between design and run mode in order to use the debugging tools. The bridge between design and run mode is called a breakpoint.

Breakpoints 101

A breakpoint is a marker in the code that allows you to stop the program while it is running in order to check some aspect of the application you're working on and then resume the run without crashing the program. You can set up any number of breakpoints in a program, and using them is easy. Look at Figure 1 again and note the white glove (or hand) icon. This is the Toggle Breakpoint icon.

To set a breakpoint in your program code, start in the Edit window containing the program source code. Locate the cursor at a starting or closing parenthesis in an expression, as if you were going to start typing at that location. Use the Toggle Breakpoint icon to enable a breakpoint at that location. Should you change your mind, locate the cursor at the same location and toggle the breakpoint again to turn it off. You can also use the function key (F9) to toggle breakpoints.

After setting the breakpoint, load the code from the Editor into the Evaluator and run it. The code executes until it reaches the breakpoint, at which time the IDE is presented, allowing you to inspect the application you're working on as if it were frozen in time.

Another way to check things out is to use the Console window (the one with the _$ prompt). At the Console you can query symbols by typing their names or evaluate expressions such as getting an entity list given an entity name. Other, better alternatives are available, which we will explore in just a second.

After looking at the variables you will want to resume or terminate the program currently running. Use the colored up arrows in the Debug toolbar to control what the Evaluator does next.

If you've spotted a problem in the code that requires source code correction before continuing or if you simply want to terminate the run, select the Reset icon (the red up arrow with two bars under it). Choosing this icon ends the run, resets all the symbols back to the values they had before the run, and puts you back in the design mode.

To resume running the program from a breakpoint, select the green Continue icon. The program will pick up and run right where it left off until it either ends or encounters another breakpoint.

Use the Quit icon (the yellow up arrow with a single bar under it) when you have breakpoints at multiple levels in a program and want to simply quit the current evaluation and return to the next higher level in the breakpoint loop.

You'll want this choice when you have a breakpoint and then want to start another function at the Console. If a second breakpoint is encountered in the second function, you will find yourself in a nested breakpoint. The use of nested breakpoints is somewhat advanced and depends largely on the application being developed. You may never need to use them or you may find them quite useful indeed.

The other icons on the Debug toolbar are for stepping through the code, and we'll explore most of them in a later article. But now let's turn our attention to some of the cool things you can do while in a breakpoint loop.

Working in the Breakpoint Loop

Although you can view the contents of symbols using the Console window, it means you must type in the name of the symbol or use it in some conversion expression (like radians to degrees). If your breakpoint is inside a program loop, and you want to see the value of some expression each time through the loop, typing in the name gets old real fast. The Watch window icon (the eyeglasses symbol in Figure 2) activates the Watch window while you're in run mode. You can place symbol names and expressions into this window to be evaluated automatically each time a breakpoint is encountered (see Figure 3).

To add a new variable for viewing in the Watch window, select the eyeglasses icon in the Watch window toolbar, which opens an edit box into which you can type the name of a symbol or an expression. The typed-in text appears in the Watch window with an equal sign followed by the current value of the variable or expression.

Suppose you are checking the value of a variable each time a loop iterates. Using the Watch window you can just keep pressing the Continue arrow until you've seen enough or determined where things are going wrong inside the loop—at which point you select the Reset arrow or remove the breakpoint and let the program run without further interruption.

Once you have resolved any problems in the source code, remove all the breakpoints and rerun the entire program. To remove all the breakpoints, select the Debug pull-down menu in the IDE and then pick the Remove all breakpoints option. You can also use the keyboard to remove all of them: press the Ctrl-Shift-F9 key combination. You can now test the complete program or application.

Wrapping Up

I hope you have enjoyed this introduction to the Visual LISP IDE and the concept of breakpoints. In the coming months we'll explore other tools in this particular IDE and how you can use them to improve your productivity.

I can't guarantee it, but as you become adept with Visual LISP tools, you may well conclude that your current application development methods are as ancient as 80-column punch cards (well, maybe not that bad).

And if you have any suggestions for future Visual LISP topics—perhaps there's something you'd like to see explained a little bit more or an example you'd like to see developed—drop me a line. Until next time, keep on programmin'!