Object Linking and Embedding (OLE)

This chapter describes how to use the OLE application framework to build OLE-enabled client applications.

First, what is OLE? This is the definition from Inside OLE (Second Edition) by Kraig Brockschmidt of Microsoft:

 

“OLE is a unified environment of object-based services with the capability of both customizing those services and arbitrarily extending the architecture through custom services, with the overall purpose of enabling rich integration between components”.

OLE is Microsoft's entry into the world of object-oriented computing. At the lowest level, object-based services are provided by C++ classes. These classes are called interfaces. Interfaces can be defined in any language but are most easily defined in C++. When one component needs to talk to another, it queries for a well-known interface. If the query succeeds, an instance of the interface is returned. Functionality is accessed using the methods of the interface. Access to the private state of the instance is not allowed.

To ensure binary compatibility and language independence in OLE, interfaces are well known and strictly defined. The fact that interfaces resemble C++ classes is incidental. Inheritance is not supported and methods are used in the same way that jump tables to functions are used in standard C.

Microsoft has defined a client/server environment for Windows where a client is defined as the user of a service and a server is defined as the provider. It is useful to partition OLE functionality in terms of client/server to focus on how OLE is used. For example, OLE provides custom control services (more commonly known as OCXs). An OCX client is any application that uses the OCX. An OCX server implements the OCX.

OLE programming is complex, error-prone, and time-consuming. To program OLE, it is necessary to implement and query many interfaces during the lifetime of the program. Because interfaces come from other applications, their behavior may or may not conform to the interface specification. In many cases, the specification is vague, making it necessary to determine behavior by experimentation.

The problem is further compounded by the fact that when writing an interface, much of the implementation can be easily and trivially defaulted, yet must be present for the interface to work. This leads to increased code bulk and complexity. The fact that there are multiple interfaces that are often tightly coupled leads to design confusion, which is often resolved by trial and error by the less-experienced OLE programmer.

To overcome the complexity of OLE, development environments normally provide a higher-level OLE application framework:

Visual C++

Microsoft provides the Microsoft Foundation Classes (MFC), a C++ class library, that comes with Visual C++. The MFC hierarchy encapsulates OLE (and Windows) in a C++ class library. Using MFC, you can access most of OLE without using low-level OLE interfaces.

 

Visual Basic

Extensions to the Visual Basic widgets and the usual syntax of Visual Basic expose OLE.

 

Smalltalk

The OLE application framework provides high-level support for writing OLE clients in VA Smalltalk.

The framework provides high-level abstractions for the OLE container concepts, thereby keeping the low-level OLE interfaces transparent to you. Using this framework, you can write OLE container applications that support embedding, linking, in-place activation, drag/drop, and structured storage. The framework supports writing OLE automation controllers, whereby third-party automation servers (such as Microsoft Word or Microsoft Excel) can be programmed from Smalltalk. In addition, you can easily and quickly incorporate arbitrary, off-the-shelf OCXs into the Smalltalk image and materialize them as Common Widgets.