Visual Basic Debugger Windows

[Previous] [Next]

So far, I've concentrated mostly on the Visual Basic debugger's limitations, not its strengths. But as I mentioned at the beginning of this chapter, the Visual Basic debugger has several features that developers love. For starters, the Visual Basic debugger is much simpler to operate than the Visual C++ debugger. It also includes some excellent supporting windows that make debugging simple. In this section, I'll go over the three Visual Basic debugger windows: Locals, Immediate, and Watch.

The Locals Window

Although the Locals window is straightforward, I want to make sure everyone knows about three key points that affect its use. The first is that, unlike the Watch window in the Visual C++ debugger, the Visual Basic Locals window doesn't require you to mess around with any sort of casting and cajoling to see the value in the appropriate format. The second is that the most important variable shown in the Locals window is the Me object. Like the C++ this pointer, the Me object is a generic construct that fully describes the current object and its properties.

The last point about the Locals window is that you can sometimes change local variables through it by selecting the variable you want to change and clicking on the Value field. If Visual Basic will allow you to change the variable, the Value field will let you edit the text. Visual Basic doesn't allow you to change objects and certain Variant variables. For example, you can't change any of the properties of controls in a form's Controls collection. However, if you have variables in your form with the actual control types, such as CommandButton, you can change the controls' properties through the variables. In cases in which you can't change a variable's value in the Locals window, you can use the Immediate window to effect the change.

The Immediate Window

In my opinion, the Visual Basic Immediate window is amazing. I wish all debuggers had such great debugging capabilities built in. While debugging, you can do anything you want to the debuggee through the Immediate window. The Immediate window is basically (excuse the pun) a mini-Basic interpreter that allows you to execute snippets of code.

The Immediate window shows the output from your Debug.Print trace statements. Keep in mind, however, that the Immediate window does limit the number of items you can display to 200 lines, so trace strings might scroll off before you read them. Unfortunately, there's no programmatic way to clear the Immediate window to ensure that you can see your important trace statements. I hope a future version of Visual Basic will offer a Debug.Clear method.

The Immediate window's main claim to fame is that you can change variable values and call routines directly in your application. To see the value of a specific variable, say frmFoo.x, in your program, you use the ? or Print statement to print out the value ? frmFoo.x. The beauty of the Immediate window is that all the wonderful Microsoft IntelliSense is built in. If you type a valid object name, IntelliSense does the work of displaying the object's methods and properties so that you can choose the one you want.

To change the value of a variable, simply type a line of Visual Basic code in the Immediate window, just as you would if you were assigning a variable in a source window. The Immediate window knows all about read-only properties and the appropriate syntax, and it will tell you through a message box if your assignment fails.

One great trick you can do in the Immediate window is to create quick test harnesses. For example, if you're developing a class, you can test that class in the Immediate window as soon as you type the code into the source editor. If the class is clsMyClass and has a method named DoSomethingMagical, you can enter the following code, line by line, into the Watch window and test the method. Make sure you always set object variables back to Nothing so that you don't run the risk of leaving initialized variables active in the Immediate window. If you have breakpoints set in DoSomethingMagical, you can single-step through your method.

Set x = New clsMyClass x.DoSomethingMagical Set x = Nothing

Another debugging trick you can perform in the Immediate window is to call your debug-only functions all you want. If you remember the byzantine rules for and limitations on calling a debugging function from the Visual C++ Watch window (see the section "Calling Functions in the Watch Window" in Chapter 5), you'll greatly appreciate the ease of using the Immediate window. The only restriction on calling functions in the Visual Basic Immediate window is that the function must exist in your program. I don't know how you could make a powerful debugging feature any easier to use.

Although the Immediate window lets you leap tall buildings in a single bound, you can't write your entire application in it. A couple of built-in constraints will prevent you from using the Immediate window the same way you use a source window. The first constraint is that you can't write functions in the Immediate window. The second is that the Immediate window executes only a single line of code at a time. Some control structures, such as For…Next loops, require multiple statements; you can use the special ":" operator to allow those control structures on a single line. The following code shows how to execute a For...Next loop in the Immediate window:

For i = 1 to UBound(a) : ? a(i) : Next i

The Watch Window

As you can guess, the Watch window is where you can watch the values of variables inside your program. You can set the scope of the variable you want to watch in the Watch window, so you can easily avoid any confusion over same-name variables in different parts of your application. The Watch window is also the place where you set your conditional breakpoints.

The Watch window lets you set only two types of conditional breakpoints: Break When Value Changes and Break When Value Is True. Setting conditional breakpoints is trivial in that you just right-click in a source window and select Add Watch from the pop-up menu. To break when the value of an expression changes, type the expression you want to watch in the Expression field and select Break When Value Changes in the Watch Type group box. To break when an expression evaluates to true, type the expression in the Expression field and select Break When Value Is True. When your application does break into the debugger, make sure you look at the Watch window because the highlighted line indicates which condition caused the breakpoint to trigger.

If you want to use skip count breakpoints such as those offered in the Visual C++ debugger, you'll need to use a counter variable that holds the number of times the function is called and use that variable in a conditional breakpoint to stop after a specific count. For the counter variable, I like to use a static local variable.

You can drag and drop variables right out of your source windows into the Watch window. What makes the drag and drop even cooler is that Visual Basic is smart enough to figure out the context for that variable, so you don't have to set it manually. Although you can also drag and drop to the Immediate window, the IDE treats such a move as a cut operation, so you'll change your source files. If you want to edit the result of a drag-and-drop watch, just right-click in the Watch window and select Edit Watch from the pop-up menu.

Before moving on to the tips and tricks section, I want to mention two final aspects of the Watch window. The first is that you can edit the values by clicking on the Value field. Just as in the Locals window, if Visual Basic will allow you to edit, you can change the value. You can also edit your expressions in place as well.

The other is that I always like to put special values, such as Err.Description, in the Watch window. That way, I can keep an eye on any error values that I might have encountered and handled as I step over entire functions. If my application also takes command-line parameters, I put Command in the Watch window so that I can quickly test the various command-line options my application might use without having to set them each time on the Make tab of the Project Properties dialog box. Unfortunately, as I mentioned at the beginning of the chapter, an incredibly annoying feature of Visual Basic is that it forgets your carefully constructed watches and breakpoints once you leave the IDE, so you must reenter them every time you start a new debugging session.