The Mechanics of OLE Automation

OLE Automation involves a controller, usually an application with a programming environment of some kind (either language or graphics based; it doesn't matter), and one or more automation objects. Because these objects can be driven from an external programming environment, they are also called programmable objects. When an entire application is structured in a way that a controller can drive it through Automation, the application is also programmable. This terminology simply means that the mechanics of Automation are involved.1

A controller is a client of one or more automation objects, for which the most important interface is IDispatch. Any object that implements this interface is said to support Automation, regardless of whether that object is packaged in a server and has a CLSID. Many automation objects are structured this way, but it is not required. Our focus here is specifically on objects with IDispatch, which is simply another mechanism through which an object shares its functionality and content but by using a late-bound mechanism. You can also use an early-bound mechanism or use type information when compiling. The capability of cross-application macro programming is an intentionally higher-level result of this mechanism.

We've seen how objects have functionality (both incoming and outgoing interfaces) and content. So far, however, we've seen only how to access an object's content as formatted data structures by using IDataObject. With IDispatch, we now have a formalized notion of individual properties—small pieces of information that work like single data members of an object. Instead of our having to ask an object for a structure of a particular format through IDataObject::GetData, we can ask for a property by name—for example, we can specify BackColor or Caption. Properties are an equivalent expression of get and put functions for data members, and they can be read-only, write-only, or read/write.

By now you know that you can easily write a custom interface that can expose an object's methods (incoming and outgoing functions) and properties in any way you like. Later in this chapter, we'll see cases in which this knowledge is useful. However, custom interfaces work best in an early-bound or compile-time manner, although they can be used in a late-bound manner with more work. The better late-bound mechanism uses the dispatch interface, or dispinterface (pronounced dis-pin-ter-face) for short.