Tips and Tricks

[Previous] [Next]

As I did in the two chapters on the Visual C++ debugger, I'll end the Visual Basic debugger chapter with some tips and tricks that can make your life easier.

Add the Run To Cursor Button to the Debug Toolbar

Like the Visual C++ debugger, the Visual Basic debugger allows you to run to the cursor position. By default, Run To Cursor is assigned to the Ctrl+F8 key combination, but I like to use the mouse when debugging, and this wonderful command isn't on the Debug toolbar. In the Customize dialog box, on the Command tab, select the Debug category and drag the Run To Cursor button to your Debug toolbar.

You might notice in Visual Basic 6 that if you do create the Run To Cursor button on the toolbar, the ToolTip for the Run To Cursor menu item says, "Step To Cursor." Just ignore the ToolTip—the button is still the Run To Cursor command. You're only seeing a small bug.

Avoid Compile On Demand

Visual Basic wants to help you debug faster by compiling only enough of your application to get it turning over in the debugger. Although the idea is sound, the problem is that you can be merrily debugging away on your application and if you hit a section that hasn't been compiled, you can have your debugging session abruptly stopped with a syntax error. If you finally got that one bug that was driving you crazy almost duplicated, stopping with a syntax error can be enough to make you throw your computer out your office door.

I always start my debugging sessions with Start With Full Compile so that I can avoid any syntax surprises. I even added a button for this command to my Debug toolbar so that I always remember to start the correct way. I also turned off Compile On Demand by unchecking it on the General tab of the Options dialog box. If you're working on a large application, you'll increase your initial debugging startup time, but at least a syntax error won't get the drop on you in the middle of a debugging session.

Group Projects Are the Way to Go for Debugging

Visual Basic 5 introduced the concept of a Group project. A Group project allows you to house all your ActiveX components along with a test harness, or your main EXE (provided it's written in Visual Basic), into one project. With all your components in the same project, you can single-step from your EXE right through your controls and DLLs. For an example, see TESTER.VBG, part of the code from Chapter 13, on the companion CD.

Visual Basic Debugging and Reality Might Conflict

As I stated earlier in this chapter, in the "Visual Basic P-Code" section, Visual Basic can debug objects only at the interpreted p-code level. In the brave new world of COM+ and Component Services, you can debug your objects with the Visual Basic debugger, but most of the documentation strongly suggests that you debug Visual Basic objects at the compiled level with the Visual C++ debugger.

For Component Services applications, I've followed the steps listed in the Visual Basic 6 READMEVB.HTM file installed as part of Visual Studio. The section "Building and Debugging MTS Components in Visual Basic 6" tells you exactly what to do to debug your applications. For COM+ applications, search MSDN for the Platform SDK topics "Debugging Components Written in Visual Basic" and "COM+ Visual Basic Debugging Support Contrasted with MTS."

To fully debug any Component Services and COM+ objects, I just compile the objects and use either SoftICE or the Visual C++ debugger. Although debugging compiled Visual Basic code isn't easy, I lighten the burden by using a slew of trace statements to view all variables and other state information I need. In the end, I feel it's better to debug Component Services and COM+ applications as compiled applications instead of working around the limitations of the Visual Basic debugger.