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