Two Ways to Package ActiveX Controls

See Also

An ActiveX control created with Visual Basic is defined by a UserControl module. The source code you add to this module, to implement your ActiveX control, is stored in a .ctl file.

You can include UserControl modules in most Visual Basic project types, but only ActiveX control projects can provide controls to other applications. Controls in all other project types are private.

Thus there are two ways to package controls:

• Public controls can only exist in ActiveX control projects. You make a control public by setting the Public property of the UserControl object to True.

  Public controls can be used by other applications, once the ActiveX control project has been compiled into a control component (.ocx file).

• Private controls can exist in any project type. You make a control private by setting the Public property of the UserControl object to False.

  After the project is compiled, private controls cannot be used by other applications. They can be used only within the project in which they were compiled.

  If you attempt to set the Public property of a UserControl object to True, and the UserControl is not in an ActiveX control project, an error occurs.

If one of the controls in an ActiveX control project is meant to be used only as a constituent of other controls in the project, you can set the Public property of the UserControl to False. The control will then be available only to the controls of which it is a constituent part. Other applications will not be able to use it.

Note   You cannot include UserControl modules in a project marked for unattended execution. If the Unattended Execution box is checked on the General tab of the Project Properties dialog box, the project cannot contain any user interface elements.

Important   If you package your controls as a control component, be sure to set the description for each control. Some clients, such as Visual Basic, represent the entire .ocx file using the string you enter in the Project Description box of the Project Properties dialog box, but others display the browser strings for the individual controls. See "Providing Help and Browser Strings for Objects," in "Debugging, Testing, and Deploying Components."

Including Controls as Compiled Code vs. Source Code

If you create your controls as public classes in an ActiveX control project, you can distribute the compiled control component (.ocx file) with any application you create. When you use SetupWizard to create a setup program for an application in which you've used such a control, the compiled .ocx file will be included automatically.

You can also create a setup program for the control component itself, and distribute it to other developers. "Licensing Issues for Controls," later in this chapter, discusses the licensing support available for control components authored using Visual Basic.

Changing the Packaging

Once you've authored a control, you can easily change the way the control is packaged.

For example, if you have some private controls that are part of a Standard EXE project, and you want to allow other applications to use them, you can add the .ctl files to an ActiveX control project, and compile it into a distributable control component (.ocx file).

Source Code

Instead of including the compiled control component in your applications, you can simply add the .ctl file to the project for the application. When the application is compiled, the control is compiled into the executable.

The primary advantages of including a control as source code are:

• There is no additional .ocx file to distribute.
  
  
• You don't have to debug your control for all possible test cases. You only have to debug the features used by your application.
  
  
• You don't have to worry about whether your application will work with future versions of the control, because the version your application uses is compiled in.

Note   Some developers may argue that avoiding the additional .ocx file is not really an advantage. All Visual Basic applications require support files, and SetupWizard automatically includes them in your setup program, so you're not avoiding any extra work.

Of course, there's no such thing as a free lunch. There are also disadvantages to including controls as source code:

• If you discover a bug in the control, you cannot simply distribute an updated .ocx file. You must recompile the entire application.
  
  
• Multiple applications will require more disk space, because instead of sharing one copy of an .ocx file, each application includes all the code for the control.
  
  
• Each time you use the source code in an application, there will be an opportunity to fix bugs or enhance the code. It may become difficult to keep track of which version of a control was used in which version of which application.
  
  
• Sharing source code with other developers may be problematic. At the very least, it's likely to require more support effort than distributing a compiled component. In addition, you give up control and confidentiality of your source code.