Lesson 5: ActiveX Controls

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:

  • 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.
Estimated lesson time: 20 minutes

ActiveX Controls and Containers

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.

click to view at full size.

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.

Features of ActiveX Controls

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.

Stock Properties

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

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.

Events

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.

Property Pages

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.

Property Persistence

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.

Lesson Summary

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.



Microsoft Press - Desktop Applications with Microsoft Visual C++ 6. 0. MCSD Training Kit
Desktop Applications with Microsoft Visual C++ 6.0 MCSD Training Kit
ISBN: 0735607958
EAN: 2147483647
Year: 1999
Pages: 95

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net