VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

Systems Analysis - System analysis and Design tutorial for Software Engineering

You are here: Visual Basic > Advanced VB6 tutorial > Chapter 18

Using the Immediate Window in Place of Breakpoints

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.


<< Previous | Contents | Next >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved