Visual Basic Concepts

Debugging Controls

The most important difference between debugging controls and debugging other objects is that some of the code in your control must execute while the form a control instance is placed on is in design mode.

For example, the code in the property procedures you use to implement your control's properties must execute when the developer using your control sets its properties using the Properties window.

Code that saves and retrieves your control's property values must also run at design time, whenever the user loads a form containing an instance of the control, puts the project in Run mode, or saves the project to disk.

Code in the Resize event (or the Paint event, for user-drawn controls) must run at design time to provide the design-time appearance of your control.

You can see this feature in action in the step-by-step procedure "Running the ShapeLabel Control at Design Time," in "Creating an ActiveX Control."

For More Information   General information on debugging components can be found in "Debugging, Testing, and Deploying Components."

Running Code at Design Time

To put a control you're authoring into a state such that its code can execute at design time, you must close the control's visual designer, by clicking the Close box or pressing Ctrl+F4.

When the designer is closed, Visual Basic enables the control's icon in the Toolbox, so that you can add instances of the control to forms for testing.

If code in your control hits a break point at design time, for example during a Property Let invoked by the Properties window, Visual Basic enters break mode, just as it would if your project were running. When you press F5 to continue execution, the code in your control resumes execution. Visual Basic remains in design mode.

You can see this by setting a break point in a property procedure, and then placing an instance of your control on a test form.

Making Changes to Existing Controls

When you open the UserControl designer for a control, Visual Basic disables all instances of the control and grays the control's icon in the Toolbox. If you have a test form open with instances of the control on it, Visual Basic covers the disabled control instances with cross-hatching.

You can also disable control instances by certain changes to code in the control's code window, such as adding a new property or method, or adding code to a previously unused event procedure.

Once a control instance has been disabled in this fashion, it cannot execute code. It will not even receive a Terminate event.

Refreshing Control Instances

When you close the UserControl designer, the disabled instances of the control are quietly destroyed (they get no more events) and replaced with fresh instances. You can see this by putting Debug.Print statements in the Initialize and Terminate events of a control.

You can also refresh the control instances by right-clicking the test form and selecting Update UserControls from the context menu. If there are any control designers open, they will be closed before the control instances are refreshed.

For More Information   General information on debugging components can be found in "Debugging, Testing, and Distributing Components."