Testing a Windows Forms Application (2 of 3)

From webpage

Testing a Windows Forms Application - How to debug runtime errors

 
(Page 2 of 3 )

When a runtime error occurs, Visual Studio enters break mode. In that mode, Visual Studio displays the Code Editor and highlights the statement that couldn't be executed, displays the Debug toolbar, and displays an Exception Assistant dialog box like the one shown in figure 3-17. This is designed to help you find the cause of the exception (the bug), and to debug the application by preventing the exception from occurring again or by handling the exception.

Often, you can figure out what caused the problem just by knowing what statement couldn't be executed, by reading the message displayed by the Exception Assistant, or by reading the troubleshooting tips displayed by the Exception Assistant. But sometimes, it helps to find out what the current values in some of the variables or properties in the program are.

To do that, you can place the mouse pointer over a variable or property in the code so a data tip is displayed as shown in figure 3-18. This tip displays the current value of the variable or property. You can do this with the Exception Assistant still open, or you can click on its Close button to close it. Either way, the application is still in break mode. In this figure, the data tip for the Text property of the txtSubtotal control is "$$1000", which shows that the user didn't enter valid numeric data.

Within the data tip, you'll see a magnifying glass and an arrow for a drop-down list. If you click on this arrow, you'll see the three choices shown in this figure. Then, if you click on Text Visualizer, the value in the data tip will be shown in the Text Visualizer dialog box the way it actually is. So in this simple example, the value will show as $$1000, not "$$1000". Although that isn't much different than what the data tip shows, the differences are more dramatic when the data is more complex.

Once you find the cause of a bug, you can correct it. Sometimes, you can do that in break mode and continue running the application. Often, though, you'll exit from break mode before fixing the code. To exit, you can click the Stop Debugging button in the Standard toolbar. Then, you can correct the code and test the application again.

For now, don't worry if you don't know how to correct the problem in this example. Instead, you can assume that the user will enter valid data. In chapter 7, though, you'll learn how to catch exceptions and validate all user entries for an application because that's what a professional application has to do. And in chapter 12, after you've learned the Visual Basic essentials, you'll learn a lot more about debugging.

How a project looks in break mode

Description

1. When an application encounters a runtime error, you need to fix the error. This is commonly referred to asdebugging, and the error is commonly referred to as a bug. 
   
2. When an application encounters a runtime error, it enters break mode. In break mode, the Debug toolbar is displayed along with the Exception Assistant window. 
    
3. The information in the Exception Assistant window should give you an idea of what the error might be. You can also click on the links in the Troubleshooting Tips list to display more information in a Help window. 
    
4. If you close the Exception Assistant window, the application remains in break mode. 
    
5. To display a data tip for a property or variable, move the mouse pointer over it in the Visual Basic code. 
    
6. If the data tip includes a drop-down arrow to the right of a magnifying glass, you can click the error and select Text Visualizer to see exactly what the data looks like. 
    
7. To exit break mode and end the application, click the Stop Debugging button in the Standard toolbar or press Shift+F5. 
    
8. You'll learn more about debugging and the Exception Assistant window in chapter 12.

 

Figure 3-18.   How to debug runtime errors