An ActiveX control is a COM object that is designed to be placed in an ActiveX control container, such as an application dialog box or on a Web page, to perform a self-contained function. ActiveX controls frequently present a graphical user interface.
This lesson gives a brief introduction to ActiveX controls and some of the considerations faced by the control developer.
After this lesson, you will be able to:Estimated lesson time: 20 minutes
- Describe the interaction between ActiveX controls and ActiveX control containers.
- Describe the interfaces that an ActiveX control must implement to meet the requirements of commonly used control containers.
- Describe some common features of ActiveX controls.
An ActiveX control is any COM object that implements the IUnknown interface and is hosted by a self-registering server that can be a DLL or an .exe file. We refer to the client of an ActiveX control as a container. ActiveX controls are located, or sited, within an ActiveX control container. Figure 8.12 shows the Microsoft Chart ActiveX control located within the ActiveX Control Test Container.
ActiveX controls usually display a user interface. In fact, many people consider the implementation of a user interface to be a defining characteristic of an ActiveX control. As we move into an age of distributed applications, there are good reasons why regular COM components should not display a user interface. For example, if your COM component displays a message box to alert you of an error condition, and the component happens to be installed on a remote server in the next building, you will not be aware that an error occurred. Most ActiveX controls, on the other hand, are tightly coupled to a container that implements a user interface. The container expects the control to participate as part of the user interface.
Figure 8.12 The ActiveX Control Test Container
Although the definition of ActiveX controls requires only that the control supports the IUnknown interface, different containers have different requirements. Some containers require certain interfaces for a control to work, while others do not. If you want your control to work with a particular container, your control must implement the interfaces required by the container.
Most of the commonly used control containers expect a control to maintain a set of data, fire events, and support enough interfaces so that a client application can successfully interact with it. Table 8.2 defines the minimum set of interfaces that the ActiveX Control Test Container (and most other user-interface containers) expects an ActiveX control to support.
Although the number of interfaces listed might imply that implementing an ActiveX control involves a lot of hard work, both MFC and ATL provide wizards that generate the basic framework of an ActiveX control. Such wizards allow you to concentrate on the implementation of the functionality specific to your control.
Table 8.2 Minimum set of interfaces to be supported by the ActiveX control
Interface | Description |
---|---|
IOleObject | Required for communication with a control's client site, except through events. Events are handled through the IConnectionPointContainer interface described later. |
IOleInPlaceObject | Implemented by controls that can be activated in place and provide their own user interface. Requires support for IOleObject. |
IOleInPlaceActiveObject | Required only by controls that provide a user interface and that support IOleInPlaceObject. |
IDataObject | Required by controls that transfer data to a container in some way, as through shared memory or a file. IDataObject provides the means for COM's Uniform Data Transfer, a protocol that sets the rules for the exchange of data of any type. |
IViewObject2 | Implemented by visible controls that display a window. |
IDispatch | Required by controls with custom methods or properties that a client can access through IDispatch::Invoke() |
IConnectionPointContainer | Required by controls that fire events. This interface enumerates for a client the events that a control object can fire. |
IConnectionPoint | Required by controls that support IConnectionPointContainer. |
IProvideClassInfo | Implemented by controls that contain type library information, which means most ActiveX controls. Through its GetClassInfo() method, the interface provides a pointer to an ITypeInfo implementation from which a client can extract the control's type information. |
IPersistStorage | Required by controls that can save and load from an IStorage instance provided by the container. |
IClassFactory | Instantiates a requested class object and returns a pointer to it. The object is identified by a CLSID registered in the system registry. |
IClassFactory2 | Same as IClassFactory, but adds support for licensing. |
ActiveX controls support properties, methods, and events to make the control programmable. ActiveX controls usually support a dispatch interface to enable a wide variety of programming languages and scripting languages to work programmatically with the control.
The ActiveX standards define a set of stock properties that are common to many controls. Examples of stock properties include the font used for text displayed by the control, and its foreground and background colors. Stock properties are distinguished from custom properties: custom properties are specific to the functionality of a control.
Ambient properties provide information to the control about the appearance of the control container. A control's properties should be set so that it appears integrated with the environment of the container. For example, the BackColor ambient property represents the background color of the container. The control can set its own BackColor stock property to this color so that the control appears to be part of the container. Control developers are encouraged to write ActiveX controls that detect and respond to the ambient properties of the container.
Controls can also respond to actions by generating events. Events are notifications from the control to the container. The event interface is defined by the control, but is implemented by the container, which makes the event interface an outgoing interface.
As with properties, a distinction is made between stock events and custom events. Stock events result from common actions such as mouse clicks or key presses. Custom events are control-specific.
Most ActiveX controls implement property pages to provide users with a graphical interface to change the properties of a control. Figure 8.12 shows the property page of the Microsoft Chart ActiveX control. Each property page is based on a dialog box template resource, and is a separate COM object with its own CLSID.
One capability of ActiveX controls is property persistence (or serialization), which allows the ActiveX control to read or write property values to and from a file or stream. A container application can use serialization to store a control's property values even after the application has destroyed the control. The property values of the ActiveX control can then be read from the file or stream when a new instance of the control is created at a later time.
ActiveX controls are regular COM objects located within an ActiveX control container. ActiveX controls implement interfaces to meet the requirements of the container. This usually involves implementing a user interface, so that the control can participate as part of the container's user interface.
ActiveX controls typically support properties, methods, and events to make the control programmable.