Share via

Visual Basic Concepts

  • Article

Special Debugging Considerations

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.

Breaking Execution During MouseDown

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.

Breaking Execution During KeyDown

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.")

Breaking Execution During GotFocus or LostFocus

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:

  • A form with a Timer control on it is running in the development environment. Selecting Options from the Tools menu will open the Options dialog box, which is modal. Until the dialog is dismissed, the Timer control's Timer event will not be raised.

  • An instance of a UserControl with a Timer control on it is placed on a form at design time. (The timer may be used to make the control appear animated; this effect can occur even in design mode, because controls can execute code at design time.) Selecting Add Class Module from the Project menu will open the Add Class Module dialog, which is modal. The Timer control's Timer event will be suppressed until the dialog is dismissed.

  • A UserDocument contains a Timer control, and a command button that displays a message box. If the UserDocument is being debugged using Internet Explorer, pressing the button to display the message box will cause the Timer control's Timer event to be suppressed until the message box is dismissed.

Testing and Using Command-Line Arguments

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

  1. From the Project menu, choose Properties.

  2. Click the Make tab on the Project Properties dialog box.

  3. Enter the sample arguments in the Command Line Arguments field. (Do not type the name of the application itself.)

  4. Choose OK.

  5. Run the application.

For More Information   See "Command Function."