Using the Debugger

The Microsoft Windows CE Toolkit for Visual Basic 6.0 includes a debugger that helps you find run-time bugs in your code. The debugger for Windows CE-based applications operates much like the debugger in Microsoft Visual Basic 6.0. For example, both debuggers support setting breakpoints, defining watch expressions, and stepping through code one statement at a time.

However, despite the overall similarity between the two debuggers, the debugger for Windows CE is specifically designed for use with Windows CE-based devices. For example, in contrast to the debugger for Visual Basic 6.0, which runs and debugs applications within a unified IDE, the toolkit debugger for Windows CE runs as a separate application outside the Visual Basic IDE.

The debugger must run as a separate application because the toolkit compiles your code into a .vb file before running it externally on a connected device or emulator. The debugger connects to the emulator or device before the application is started, launches the application under its control, and remains connected while the application runs. Closing your application automatically closes the debugger.

Another difference to be aware of when writing applications is that, unlike the applications you create with Visual Basic 6.0, a Windows CE-based application cannot directly communicate with the debugging environment by means of the Stop command or the Debug object. All debugging actions must be initiated from the debugger IDE.

The following sequence of steps gives an overview of the debugging process:

  1. Choose Step Into or Go from the Debug menu in the IDE to start the debugger. You must execute subsequent commands from inside the debugger itself, not from the IDE.
  2. Use the F9 key to set breakpoints.
  3. Trace through the code using the Step commands.
  4. Analyze objects and variables using the Watch and Immediate windows.
  5. Exit the debugger.
  6. Modify the application.
  7. Recompile the application and repeat the process.

Note When you debug applications in emulation, you may find it convenient to move the debugger window away from the emulator. When you are debugging a procedure step-by-step and the debugger is covering a form, the emulator does not repaint the form until the call stack is empty and the procedure returns.