Visual Basic Concepts
Control Creation Terminology
Controls are unlike other objects you create with Microsoft Visual Basic. They're not just code; they have visual parts, like forms — but unlike forms, they can't exist without some kind of container. In addition, controls are used — in different senses — by both developers and end users of applications.
These characteristics of controls require some additional terminology.
Control Class vs. Control Instance
The control you develop in Visual Basic is actually a control class, a description from which controls will be created. When you put a control on a form, you're creating an instance of this control class.
To avoid confusion, remember that the control class you're designing is distinct from the control instances you place on forms.
Control vs. Control Component
Controls are objects provided by control components, also known as .ocx files. A control component may provide more than one kind of control.
An ActiveX control project contains one or more .ctl files, each of which defines a control class. When you build the project, Visual Basic gives the control component an .ocx extension.
A developer who buys your control component and installs it can use any of the controls you defined (and made public).
Containers and Siting
A control instance cannot exist by itself. It must be placed on a container object, such as a Visual Basic form. The process of hooking a control instance up to its container is called siting — that is, assigning the control a site on the container.
When a control instance has been sited, its events are available as event procedures in the form's code window, and it has access to other services the container provides, such as Extender and AmbientProperties objects.
Interface vs. Appearance
A control consists of three parts, two public and one private. The control's appearance is public, because users see and interact with it. The control's interface — the set of all its properties, methods, and events — is also public, because it's used by any program that includes instances of the control.
The private part of a control is its implementation, the code that makes the control work. The effects of a control's implementation can be seen, but the code itself is invisible.
Author vs. Developer
The author of a control compiles her project as a control component, or .ocx file, which may contain one or more controls. A developer uses the control (or controls) to create an application, and includes the .ocx file in their setup program. The user installs and uses the application.
These terms avoid confusion between the developer of a control and the developer who uses the control in an application. The former will be referred to throughout as the author of the control.
For example, the author of the control is the only person who can place code in the event procedure for the UserControl object's Click event.
If she ends that code by raising her own Click event, the developer who adds an instance of the control to one of his forms will have an event procedure in which to place code he wants to execute when the user of his application clicks on that control instance.
When the user of the application clicks on the control, the author's code and the developer's code get executed.
Note Developers are not the only direct consumers of ActiveX controls. You can design controls for users to place on documents in desktop applications such as Microsoft Office.
Design-Time Instance vs. Run-Time Instance
When a Visual Basic user puts a control on a form at design time, an actual instance of the control class is created. The user thinks of this control as a permanent fixture of the form. In fact, it's only a design-time instance; if the form is closed for any reason — clicking its Close button, closing the project, or pressing F5 to place the project in Run mode — this design-time instance is destroyed.
If the project is placed in Run mode, a run-time instance of the control is created when the form is loaded. This run-time instance is destroyed when the form is unloaded. When the form once again appears in design mode, a new design-time instance of the control is created.
A new design-time instance is also created the first time the form's .frm file is opened, after the project that contains the form is opened in the development environment. The .frm file contains all the values of the control instance's properties.
The property values in the in-memory copy of the .frm file are used by Visual Basic to re-create the control as modes change. When you make the project into an executable, the property values it contains are compiled in, so that a run-time instance of the control can be created when the compiled application is run.
Control lifetime is discussed in more detail in "Understanding Control Lifetime and Key Events," later in this chapter.