Ole
Ole
OLE is a mechanism that allows users to create and edit documents containing items or
"objects" created by multiple applications. OLE was originally an acronym for Object
Linking and Embedding. However, it is now referred to as OLE. Parts of OLE not related
to linking and embedding are now part of Active technology
You use a container application to create compound documents and a server application
or component application to create the items within the container document. Any
application you write can be a container, a server, or both.
OLE incorporates many different concepts that all work toward the goal of seamless
interaction between applications. These areas include the following:
Linking and embedding are the two methods for storing items created inside an
OLE document that were created in another application. For general information
on the differences between the two,
Automation
Compound Files
Uniform Data Transfer (UDT) is a set of interfaces that allow data to be sent and
received in a standard fashion, regardless of the actual method chosen to transfer
the data. UDT forms the basis for data transfers by drag and drop. UDT now
serves as the basis for existing Windows data transfer, such as the Clipboard and
dynamic data exchange (DDE).
The Component Object Model (COM) provides the infrastructure used when OLE
objects communicate with each other. The MFC OLE classes simplify COM for
the programmer. COM is part of Active technology, because COM objects
underlie both OLE and Active technology.
Using the Paste command in a container application can create an embedded component,
or embedded item. The source data for an embedded item is stored as part of the OLE
document that contains it. In this way, a document file for a word processor document
can contain text and also can contain bitmaps, graphs, formulas, or any other type of data.
OLE provides another way to incorporate data from another application: creating a linked
component, or linked item, or a link. The steps for creating a linked item are similar to
those for creating an embedded item, except that you use the Paste Link command
instead of the Paste command. Unlike an embedded component, a linked component
stores a path to the original data, which is often in a separate file.
For example, if you are working in a word processor document and create a linked item
to some spreadsheet cells, the data for the linked item is stored in the original spreadsheet
document. The word processor document contains only the information specifying where
the item can be found, that is, it contains a link to the original spreadsheet document.
Every OLE item, whether embedded or linked, has a type associated with it based on the
application that created it. For example, a Microsoft Paintbrush item is one type of item,
and a Microsoft Excel item is another type. Some applications, however, can create more
than one item type. For example, Microsoft Excel can create worksheet items, chart
items, and macrosheet items. Each of these items can be uniquely identified by the
system using a Class Identifier or CLSID.
Most servers are stand-alone applications or full servers; they can either be run as stand-
alone applications or can be launched by a container application. A miniserver is a special
type of server application that can be launched only by a container. It cannot be run as a
stand-alone application. Microsoft Draw and Microsoft Graph servers are examples of
miniservers.
Containers and servers do not communicate directly. Instead, they communicate through
the OLE system dynamic-link libraries (DLL). These DLLs provide functions that
containers and servers call, and the containers and servers provide callback functions that
the DLLs call.
Using this means of communication, a container does not need to know the
implementation details of the server application. It allows a container to accept items
created by any server without having to define the types of servers with which it can
work. As a result, the user of a container application can take advantage of future
applications and data formats. If these new applications are OLE components, then a
compound document will be able to incorporate items created by those applications.
Depending on your application, there are four possible implementation strategies for
adding OLE support:
This situation usually requires the least work. You run the MFC Application
Wizard and select either Advanced Features or Compound Document Support to
create a skeleton application.
• You have a program written with the Microsoft Foundation Class Library version
2.0 or higher that does not support OLE.
• You have an application that was not written using the Microsoft Foundation
Classes and that may or may not have implemented OLE support.
This situation requires the most work. One approach is to create a new
application, as in the first strategy, and then copy and paste your existing code
into it. If your existing code is written in C, then you may need to modify it so it
can compile as C++ code. If your C code calls the Windows API, then you do not
have to change it to use the Microsoft Foundation classes. This approach likely
will require some restructuring of your program to support the document/view
architecture used by versions 2.0 and higher of the Microsoft Foundation Classes.
Once you have decided on a strategy, you should either read the Containers or Servers
articles (depending on the type of application you are writing) or examine the sample
programs, or both. The MFC OLE samples OCLIENT and HIERSVR show how to
implement the various aspects of containers and servers, respectively
Because of the size and complexity of the raw OLE API, calling it directly to write OLE
applications can be very time consuming. The goal of the Microsoft Foundation Class
Library implementation of OLE is to reduce the amount of work you have to do to write
full-featured, OLE-capable applications.
This article explains the parts of the OLE API that have not been implemented inside
MFC. The discussion also explains how what is implemented maps to the OLE section of
the Platform SDK.
A few interfaces and features of OLE are not directly provided by MFC. If you want to
use these features, you can call the OLE API directly.
The IMoniker interface is implemented by the class library (for example, the
COleServerItem class) but has not previously been exposed to the programmer.
For more information about this interface, see OLE Moniker Implementations in
the OLE section of the Platform SDK.
The IUnknown interface is implemented by the class library but is not exposed to
the programmer. The IMarshal interface is not implemented by the class library
but is used internally. Automation servers built using the class library already
have marshaling capabilities built in.
Compound files are partially supported by the class library. None of the functions
that directly manipulate compound files beyond creation are supported. MFC uses
class COleFileStream to support manipulation of streams with standard file
functions. For more information,
In-process servers and object handlers allow implementation of visual editing data
or full Component Object Model (COM) objects in a dynamic-link library (DLL).
To do this, you can implement your DLL by calling the OLE API directly.
However, if you are writing an Automation server and your server has no user
interface, you can use AppWizard to make your server an in-process server and
put it completely into a DLL.