Changes in the Debugger

Changes in the Debugger

Visual Basic .NET shares the same debugger with all .NET languages in Visual Studio .NET. This debugger works much the same as the one in Visual Basic 6 in that you can step through code and set breakpoints in the same way. However, there are some differences that you should be aware of. These are discussed in the following sections.

No Edit and Continue

What percentage of your Visual Basic 6 application would you say is developed when you are debugging your application in what is commonly referred to as break mode? Ten percent? Forty percent? Ninety percent? Whatever your answer, the number is likely above zero. Any problems you encounter while debugging your Visual Basic 6 application are quite easy to fix while in break mode. This is a great feature that allows you to create applications more quickly. You will miss this ability in Visual Basic .NET.

The Visual Studio .NET common debugger does not allow you to edit your code while in break mode. Any time you encounter code that you want to change or fix, you need to stop debugging, make the change, and then start the application again. Doing so can be a real pain.

The Visual Basic .NET team recognizes that this is not what you would call a RAD debugging experience. The team hopes to offer an updated debugger that supports edit and continue in a future release of Visual Studio .NET. Until then, prepare to break, stop, edit, and rerun your application.

Cannot Continue After an Error

If an error or exception occurs while you are running your application, the Visual Basic .NET debugger will stop at the point where the exception occurred. However, unlike Visual Basic 6, in the Visual Basic .NET debugger you cannot fix your code or step around the code that is causing the error. If you attempt to step to another line, the application will terminate and switch to Design view. You will need to determine the source of the exception, fix your code, and then rerun the application.

No Repainting in Break Mode

In Visual Basic 6, the form and all controls on it continue to display even when you are in break mode. This happens because the Visual Basic 6 debugger lets certain events occur and allows certain code to execute when you are in break mode. For example, painting is allowed to occur.

When debugging your application using Visual Basic .NET, you will find that your form does not repaint. In fact, if you place another window over it while you are in break mode, you will find that the form image does not update at all. The Visual Basic .NET debugger does not allow any events or code to run while you are in break mode.

One benefit of the Visual Basic .NET debugger is that you can debug your paint code and watch your form update as each statement that paints the form executes. It allows you to pinpoint the exact statement in your code that is causing a problem with the display. Because the Visual Basic 6 debugger allows the form to repaint constantly, it is difficult to pinpoint painting problems using the Visual Basic 6 debugger.