Certain events that are a normal part of using Microsoft Windows can pose special challenges when you’re debugging an application. It’s important to be aware of these issues so they don’t confuse you or complicate the debugging process.
If you keep in mind that suspending execution can put events at odds with what your application expects, you can usually find solutions. You may need to use the Print method of the Debug object instead of breakpoints to monitor values of properties or variables. You may also need to change the values of variables that depend on the sequence of events.
If you suspend execution during a MouseDown event procedure, you can release the mouse button or use the mouse to do any number of tasks. However, when you continue execution, the application assumes that the mouse button is still pressed down. A MouseUp event doesn’t occur until you press the mouse button down again and release it.
However, when you press the mouse button down after you continue execution, you once again suspend execution in the MouseDown event procedure. In this scenario, the MouseUp event never occurs. The typical solution is to remove the breakpoint in the MouseDown event procedure and use the Print method of the Debug object to determine the status of any variables.
If you suspend execution during a KeyDown event procedure, considerations similar to those during a MouseDown event procedure apply. If you retain a breakpoint in a KeyDown event procedure, a KeyUp event may never occur.
If you suspend execution during a GotFocus or LostFocus event procedure, the timing of system messages may cause inconsistent results. You can avoid this problem by using the Print method of the Debug object instead of suspending execution in GotFocus or LostFocus event procedures.
See Also For more information on using events, see Chapter 6, “Responding to Events.”