ActiveX and the Component Object Model
ActiveX automation, controls, and documents are based on the Microsoft Component Object Model (COM), which defines the rules for building, deploying, and using ActiveX applications. COM is a binary standard and consists of a set of rules used to build language-independent, object-oriented applications. As a result, COM applications are characterized by Application Programming Interfaces (APIs) that are object-oriented and language-independent. These APIs provide considerable advantages over traditional APIs, which are either flat (like a C library) or are language bound (like a C++ class hierarchy). COM encourages interface-based programming rather than object-based programming, which leads to better encapsulation, proper versioning, and easier reuse of applications.
Using the Distributed Component Object Model (DCOM), most COM applications also can be deployed on remote server machines and reused from client machines on the same network. For example, you can use DCOM to build a remote data acquisition application in which the acquisition is performed by a DCOM server application running on a Windows server machine connected to a Local Area Network (LAN). ActiveX client applications running on other Windows machines on the same LAN can connect to the server machine and get the acquired data. The client applications can then perform analysis on the data, publish the data on the Internet, and so on.
COM Applications, Objects, and Interfaces
A COM application consists of one or more COM objects. For example, the Microsoft Word ActiveX server contains COM objects to represent a Word document. A COM object is an entity that encapsulates some data, or properties, and implements some functionality, or methods. These properties and methods are similar to the attributes and functions associated with LabWindows/CVI User Interface controls. The generic type of a COM object is referred to as a COM class (or coclass). The methods and properties are arranged in groups called interfaces, and each COM object implements one or more interfaces. A COM interface is a table of pointers to functions that implement the methods and properties. This table is commonly referred to as a v-table because in C++, the table contains virtual functions.
Typically, COM programmers design interfaces by grouping the data and functionality required to solve their problem in logically coherent sets. An interface typically represents a behavior in the problem domain. Programmers then design their COM classes by developing different object types to represent entities that implement various combinations of interfaces, based on the different behaviors that these entities manifest. This process is called interface-based programming. Finally, programmers design the COM application as a framework or hierarchy of these COM objects. The design process, like all object-oriented design processes, is iterative and goes through many cycles before the final interfaces, object types, and object hierarchy are finalized.
For example, consider building a GPIB instrument driver that can be used as an ActiveX server. The design process involves creating interfaces that expose the various capabilities of the instrument, such as acquisition and waveform generation, and then building a hierarchy of ActiveX objects that implement these interfaces. A trivial hierarchy can contain a single object that exposes all the interfaces. A nontrivial, but simple, hierarchy can contain multiple ActiveX objects. Each object exposes a single interface, and the interfaces have methods and properties that you can use access other objects in the hierarchy. In the second hierarchy, one object may implement the acquisition interface, another may implement the waveform generation interface, and so on. In any hierarchy, one or more objects must be top-level objects, which ActiveX clients can create directly, and the other objects must be sub-objects, which ActiveX clients can obtain only by accessing the methods and properties of other objects. Instrument drivers, like IVI drivers, might require hierarchies that are more complex than the preceding examples.
The following figure shows the standard representation of a COM object. The lines represent the interfaces implemented by the object. The IUnknown interface is distinguished by its upper-right corner position in the representation.
 |
Note All COM interfaces are derived from an interface called IUnknown. IUnknown provides basic functionality such as verifying object identity, getting information about the interfaces implemented by the object, and managing the lifetime of the object. |
