MFC Library Reference OLE Background

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

OLE documents, historically called compound documents, seamlessly integrate various

types of data, or components. Sound clips, spreadsheets, and bitmaps are typical
examples of components found in OLE documents. Supporting OLE in your application
allows your users to use OLE documents without worrying about switching between the
different applications; OLE does the switching for you.

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

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,

In-Place Activation (Visual Editing)

Activating an embedded item in the context of the container document is called

in-place activation or visual editing. The container application's interface changes
to incorporate the features of the component application that created the
embedded item. Linked items are never activated in place because the actual data
for the item is contained in a separate file, out of the context of the application
containing the link.

Automation

Automation allows one application to drive another application. The driving

application is known as an automation client, and the application being driven is
known as an automation server or automation component. Automation works in
both OLE and Active technology contexts. You can automate any object based on
COM.

Compound Files

PRASHANT SHARMA : prashant1786@yahoo.com 1

 Compound files provide a standard file format that simplifies structured storing of
compound documents for OLE applications. Within a compound file, storages
have many features of directories and streams have many features of files. This
technology is also called structured storage

Uniform Data Transfer

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).

Drag and Drop

Drag and drop is an easy-to-use, direct-manipulation technique to transfer data

among applications, among windows within an application, or even within a
single window in an application. The data to be transferred is selected and
dragged to the desired destination. Drag and drop is based on uniform data
transfer..

Component Object Model

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.

OLE Background: Linking and Embedding

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.

PRASHANT SHARMA : prashant1786@yahoo.com 2

When you double-click the cells, the spreadsheet application is launched and the original
spreadsheet document is loaded from where it was stored.

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.

OLE Background: Containers and Servers

A container application is an application that can incorporate embedded or linked items

into its own documents. The documents managed by a container application must be able
to store and display OLE document components as well as the data created by the
application itself. A container application must also allow users to insert new items or edit
existing items by activating server applications when necessary.

A server application or component application is an application that can create OLE

document components for use by container applications. Server applications usually
support drag and drop or copying their data to the Clipboard so that a container
application can insert the data as an embedded or linked item. An application can be both
a container and a server.

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.

OLE Background: Implementation Strategies

Depending on your application, there are four possible implementation strategies for
adding OLE support:

PRASHANT SHARMA : prashant1786@yahoo.com 3

 • You are writing a new application.

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.

Create a new application with the MFC Application Wizard as previously

mentioned, and then copy and paste the code from the new application into your
existing application. This will work for servers, containers, or automated
applications..

• 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

OLE Background: MFC Implementation

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.

Portions of OLE Not Implemented by the Class Library

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.

PRASHANT SHARMA : prashant1786@yahoo.com 4

IMoniker Interface

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.

IUnknown and IMarshal Interfaces

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.

Docfiles (Compound Files)

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

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.

PRASHANT SHARMA : prashant1786@yahoo.com 5