Once upon a time, debugging an application meant running the code and hoping to get an error message that would tell you the line number on which your application failed. The next step was to print your application code on that wide green and white striped paper with holes on each side and take it home. Then you would spend the rest of the evening reading through the code with a marker, circling different variables and making notes. Finally, you might have had a few ideas to try and headed into work. The next day was much of the same.
For the last decade we've had a number of debuggers with several tools for investigating different aspects of the problem. These tools speed up the process of debugging applications and allow the developer to spend more time addressing business problems and less time mired in code searching of a simple syntax error.
As programming techniques have advanced and the interaction and coordination with a variety of different platforms has increased, there has been a need for more advanced
debugging tools. Visual Studio .NET provides numerous debugging tools (shown in Figure 5- 7), including windows for viewing internal aspects of your application while it runs, advanced tools for managing break-points, and the ability to quickly and easily access code which may reside in a number of different components:
• The Locals window displays all variables in the current procedure.
• The Autos window displays all variables in the current and previous statements. • The Watch window displays values for selected variables.
• The Quick Watch dialog allows for quick viewing of any variable and works closely with the Watch Window.
• The Call Stack window displays the names of functions used to the point of current execution.
• The Command window is a replacement of the immediate window provided by Visual Studio 6.
Figure 5-7: The many debugging tools available at runtime. The following sections will talk about these tools in more detail.
Locals Window
The Locals window (Figure 5-8) displays all variables in the current procedure. All values in the Locals window are updated only when a breakpoint is reached. During execution, the values displayed become outdated until the next break-point; during a breakpoint you can modify these values.
Figure 5-8: The Locals window.
Autos Window
The Autos window (Figure 5-9), in break mode, displays all the variables and their values for the current and previous statements. The values of the variables can be modified while in break mode by double-clicking them in the Autos window and inputting new ones.
Figure 5-9: The Autos window.
The Watch window, which is discussed in the following section, is similar to the Autos window except that all values are automatically tracked in the Autos window while only selected values are tracked if you specifically add them to them to the Watch window.
Watch Window
Like the Locals window, the Watch window (Figure 5-10) displays information about variables including the variable name, value, and type. The Watch window differs from the Locals window because it displays values for variables specifically requested while the Locals Window displays all variables in the current procedure. Another significant difference is that values in the Watch window are always current, which means that you can trust the values they display while your application is running.
Figure 5-10: The Watch window.
To add a variable to the Watch window, simply right-click the variable in the code window and select Add Watch. To remove a variable from the Watch window, right-click the variable in the Watch window, and select Delete Watch. To change a value in the Watch window, double-click the Value column and enter the new value.
QuickWatch Dialog Box
The QuickWatch window (Figure 5-11) works closely with the Watch window. This dialog allows you to take a quick look at variables rather than adding them to the Watch window then later having to remove them.
Figure 5-11: The QuickWatch dialog box.
Before committing to using any variable in the Watch window, you can right-click the
variable and select QuickWatch. From here, you can quickly evaluate the variable value, then decide whether or not to add it to the Watch window for future use.
Call Stack Window
The Call Stack window, shown in Figure 5-12, displays the names of functions used up to the current point of execution. You can add, disable, or remove breakpoints simply by right- clicking on the desired procedure name and selecting a breakpoint option.
Figure 5-12: The Call Stack window.
Double-click a procedure name in the Call Stack window to view the code behind that procedure. If you happen to double-click a procedure name for which the code is not
available, a Disassembly window is displayed. If the Disassembly window has the focus when double-clicking a procedure name, your code is disassembled and displayed.
The Call Stack window also provides easy access to SQL Server Stored Procedures. Stored procedures show up in the Call Stack window just like any other procedure and can be treated as such. Breakpoints can also be added to stored procedures, which will display the stored procedures source code for debugging purposes.
Command Window
In Chapter 3, "Visual Studio.NET Walkthrough," you learned about the various uses and functions that are provided by the Command window. It is important to note, however, that in the context of debugging, the Command Window has assumed the functionality of the
Immediate window from Visual Studio 6.
Breakpoints
Breakpoints determine when to pause the execution of code and are useful when debugging or testing a code segment. This is often handy when skipping through code to a specific point where heavy scrutiny is needed. At this point, other debugging windows can be used, such as the Locals, Watch, Autos, or Command window.
The Breakpoints window (Figure 5-13) provides a central location for managing all
breakpoints throughout the application. Select Windows from the Debug menu and then select Breakpoints to access the Breakpoints window.
Figure 5-13: The Breakpoints window.
The Breakpoint window provides a variety of configuration settings for breakpoints including the ability to create new breakpoints. The source code behind a breakpoint can be displayed by right-clicking the breakpoint and selecting Go To Source Code or by double-clicking the breakpoint in the Breakpoint window.
Right-clicking any breakpoint in the Breakpoint window and selecting properties displays the Breakpoint Condition dialog box (Figure 5-14). Here you are able to set properties that determine when a breakpoint is executed such as Hit Count and when a value is true or has changed.
Figure 5-14: The Breakpoint Condition dialog box lets you configure conditions for a Breakpoint.