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 19

Using Project Groups to Debug an ActiveX Control

Another feature of Visual Basic, the capability to develop your own ActiveX controls, naturally works well with the concept of project groups.

Whenever you develop an ActiveX control, it is a good idea to add some other project to your project group—before you run, test, or debug your control. You really don’t need to have anything more than a single form in the test project, but this testing method, of course, always requires the use of a group.

This is because the test project has to be separate from the ActiveX control’s project. As in the previous DLL examples, you can use all the debugging features of Visual Basic when working with your ActiveX control in a project group. Using breakpoints, you can cause Visual Basic to pause execution at any point in your control, or in the code of the host project. When stepping through code, the entire project group is treated as one complete, uninterrupted collection of code. You can step directly from a line of code in the host project to a line in your control, transparently. The Error-Trapping settings also function as in the DLL examples: The settings always affect all projects in the group. Exercise 19.4 illustrates the various debugging methods with an ActiveX control.

Overall, there are only a few important differences about working with ActiveX controls rather than DLLs in project groups:

  • You do not need to create a reference to the control in your other projects in the same project group. The control is always available on the ToolBox, and a reference is automatically created for you when you place the control on to any of your forms in the test project.

  • Although the ActiveX control you’re working on becomes immediately visible in the VB ToolBox, you can’t use it in the text project unless you have closed the ActiveX control’s designer. It will remain disabled on the ToolBox until you close the ActiveX designer.

  • Breakpoints placed in key startup code (such as the UserControl’s Initialize event) can prevent proper display or functioning of the control during design time.

The first difference is not a problem; it is merely a convenience not provided for ActiveX DLLs, and saves you a few seconds of effort. Because you have to load the control into another project before you can run it, every project in the group references the control by default.

The second and third points are a bit more of an issue, and they exist because of the differences between DLLs and controls. ActiveX controls have a visual interface at design time, so their code is loaded into memory and executed even when you are not running the project.

Visual Basic is not really in Execution mode at this point, however, so it is not possible to debug what happens when the code is run at this point.

Errors in your ActiveX control project can cause error messages when placing an instance of your control on a form in the test project.
FIGURE 19.11 Errors in your ActiveX control project can cause error messages when placing an instance of your control on a form in the test project.

If you attempt to open a form containing your control, and the control has an error, you will receive an error message, as shown in Figure 19.11, and the form will not be opened. Fortunately, you have the option to enter Debug mode at this point, enabling you to fix the problem. Exercise 19.5 takes you through a series of steps to demonstrate the design-time effects of breakpoints and errors in an ActiveX control project.

<< Previous | Contents | Next (Chapter 20) >>

Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved