Managing Breakpoints

Breakpoints are the mainstay of application debugging. Press F9 on a line of code to toggle breakpoints on and off. Breakpoints are apparently one of the first things that programmers thought of when they created the operating system. Way back to MS-DOS and to this day, interrupt 3 ”a system “level function ”is the debug, or breakpoint, interrupt. You can still insert an int 3 instruction in an assembly language program (or even using the debug.exe application) and the program will break at that point. Fortunately, all we have to do is hit F9 and the mechanics are handled for us.

Adding a breakpoint to a line of code causes an application running in the IDE to stop at that line. The presence of a breakpoint is indicated by a small red circle in the margin of the Code Editor and a red background highlighting the line of code where the debugger will stop.

You can choose to set, enable, disable, edit, and delete a breakpoint. You can also manage breakpoints by using a conditional expression or hit count. Unfortunately, only Visual C++ seems to support data breakpoints. (A data breakpoint is a break set on a piece of data; when the data's value changes the debugger breaks.)

The DebugWindowsBreakpoints window (Figure 17.5) is the easiest place to manage all the breakpoints in your application. For example, you can edit the breakpoint in line 491 (in the actual code, when the form generated portion is expanded) of the Form1.vb source file for the Calculator application by selecting Properties from the context menu. This opens the Properties window (Figure 17.6). You also have the option of right-clicking on the breakpoint line (highlighted in red) and selecting items from the context menu.

Figure 17.5. Use the DebugBreakpoints window to manage all breakpoints in your application.

Figure 17.6. Use the Breakpoint Properties window to fine-tune your breakpoints.

Two easy-to-implement and common modifications are (1) to break when a breakpoint has been hit a certain number of times, for example, near the end of a loop condition, and (2) to add an expression to the breakpoint, breaking when a condition is met at that point in your application. The default breakpoint ”indicated when you press F9 ”is to always break without condition, as indicated in Figure 17.6. If you want to break on a condition, click the Condition button and indicate the condition. If you want to break after the breakpoint has been hit a certain number of times, click the Hit Count button and indicate the number of times. Figure 17.7 shows the Breakpoint Condition dialog, which indicates that the breakpoint should occur only when ValidOperation(Op) = True .

Figure 17.7. Use the Breakpoint Condition dialog to set a breakpoint condition.

You will probably use a simple breakpoint most often, but if you discover an error that occurs only intermittently, it may be too tedious to break continuously. Under these circumstances conditional breakpoints help speed up debugging.