Many of the techniques that have been used in this chapter to display data
require a program to be in Break mode. Sometimes, however, that can cause problems.
If you know when Break mode can give you fits, you can use
Debug.Print to get the information you need in the Immediate window instead
of setting watches or breakpoints.
Using the MouseDown and KeyDown Events
The first potential problem occurs in association with key events and mouse
events. If you enter Break mode during a MouseDown or
KeyDown event, you are probably going to release the key or mouse button
while you are still in Break mode. After all, you need to use the keyboard and
the mouse yourself to carry out your debugging tasks. If you break execution during
either of these events and then resume program execution, your application doesn’t
know enough to trigger a MouseUp or
KeyUp event for you. After all, when it went to sleep the button or key
was down; and now that it is awake, it thinks that’s still the case.
To get the MouseUp or KeyUp
event, you need to press the button or key again and release it. But that’s
where the program goes into Break mode again (a veritable "Catch-22"),
so you never really get to the MouseUp or
KeyUp events.
Solution: Don’t enter Break mode in these events. Instead,
use Debug.Print to display the necessary data in the
Immediate window.
Using the GotFocus and LostFocus Events
The problem here doesn’t pose the same logical difficulty presented by
the MouseDown and KeyDown events.
Instead, a breakpoint in GotFocus or
LostFocus can just throw off the timing of system messages as they are
sent. Windows is so sensitive to the timing of system messages that the API even
includes several different ways to dispatch them.
SendMessage will send a message to the target object,
for example, waiting until the message has been successfully sent before returning
a value. PostMessage, on the other hand, returns at
once after adding its message to the queue; it doesn’t wait for the results.
Function calls seem to occur so quickly that it may seem strange to think that
the difference would be so important as to require a different function.
Remember that a computer’s memory access is measured in nanoseconds,
however, and perhaps it will make more sense.
Timing is critical, and a breakpoint in the Focus events can mess things up.
If you need to display values during a GotFocus or
LostFocus event, use Debug.Print to send the
data to the Immediate window.
