Using the Debug Perspective

The first time you execute IDL code that contains an error or a breakpoint, the IDL Workbench will ask if you want to switch to the Debug perspective. Depending on how you answer the question, the Workbench will either switch automatically to the Debug perspective, stay in the IDL perspective, or ask you again. See Automatic Perspective Switching for details.

The Debug perspective looks something like this:

We'll look at a few of the important views in the Debug perspective individually.

Debug View

The Debug view provides a graphical representation of the call stack of your program and the place where the IDL interpreter has stopped, either due to an error in the code or a breakpoint you inserted. At the bottom of the call stack is IDL's $MAIN$ context. A program called from $MAIN$ sits "on top" of $MAIN$ in the call stack; similarly, programs called from other programs sit "above" in the stack. In our example, the Debug view depicts execution stopped in a routine called BREAKPOINT_TEST, which was called from the IDL command line ($MAIN$).

The toolbar in the Debug view allows you to control execution of your IDL code. See The Debug View for a complete description.

Editor

The editor functions identically in the Debug and IDL perspectives. Often, however, when you are using the Debug perspective the editor shows a file in which IDL execution has halted, either due to an error or a breakpoint. The instruction pointer is a blue arrow in the grey left-hand margin of the editor; it indicates the line on which execution was halted. In the image above, the instruction pointer arrow shows that execution was halted on a line containing a breakpoint.

Breakpoints View

The Breakpoints view gives you the tools to manage your code breakpoints. By default, the Breakpoints view displays all breakpoints for all files included in open projects in the current workspace. See Breakpoints View for additional details.

Variables View

The Variables view displays the values of variables in the current execution scope. This means that when execution has halted, only the variables in the scope of the routine that was running will be visible.

You can use the Variables view to inspect or change variable values, as described in Profiling Your Code. See Variables View for additional details on the view itself.