Certain events that are a common part of using Microsoft Windows can pose special problems for debugging an application. It's important to be aware of these special problems so they don't confuse or complicate the debugging process.
If you remain aware of how break mode can put events at odds with what your application expects, you can usually find solutions. In some event procedures, you may need to use Debug.Print statements to monitor values of variables or properties instead of using watch expressions or breakpoints. You may also need to change the values of variables that depend on the sequence of events. This is discussed in the following topics.
If you break execution during a MouseDown event procedure, you may release the mouse button or use the mouse to do any number of tasks. When you continue execution, however, the application assumes that the mouse button is still pressed down. You don't get a MouseUp event until you press the mouse button down again and then release it.
When you press the mouse button down during run time, you break execution in the MouseDown event procedure again, assuming you have a breakpoint there. In this scenario, you never get to the MouseUp event. The solution is usually to remove the breakpoint in the MouseDown procedure.
If you break execution during a KeyDown procedure, similar considerations apply. If you retain a breakpoint in a KeyDown procedure, you may never get a KeyUp event. (KeyDown and KeyUp are described in "Responding to Mouse and Keyboard Events.")
If you break execution during a GotFocus or LostFocus event procedure, the timing of system messages can cause inconsistent results. Use a Debug.Print statement instead of a breakpoint in GotFocus or LostFocus event procedures.
The development environment cannot raise events while a modal form or message box is displayed, because of potential conflicts in the debugger. Therefore, events are suppressed until the modal form or message box is dismissed.
Important Suppression of events only happens in the development environment. Once a project is compiled, events will be raised even when a modal form or message box is displayed.
Some example scenarios in which this can occur:
You can choose to have your application use command-line arguments, which provide data to your application at startup. The user can enter them by choosing the operating environment's Run command, and then typing arguments after the application name. You can also use command-line arguments when creating an icon for the application.
For example, suppose you create an alarm clock application. One of the techniques for setting the alarm time is to let the user type in the selected time directly. The user might enter the following string in the Run dialog box:
Alarm 11:00:00
The Command function returns all arguments entered after the application name (in this case, Alarm). The Alarm application has only one argument, so in the application code, you can assign this argument directly to the string that stores the selected time:
AlarmTime = Command
If Command returns an empty string, there are no command-line arguments. The application must either ask for the information directly or select a default action.
To test code that uses Command, you can specify sample command-line arguments from within the Visual Basic environment. The application evaluates sample command-line input the same way it does if the user types the argument.
To set sample command-line arguments
For More Information See "Command Function."