InformIT: Visual C++ 6 Unleashed > Some Details About Active Document Containers

Table of Contents

Some Details About Active Document Containers

Active document containers have a rich history. Their roots go back to the first release of OLE, when OLE meant object linking and embedding. The original intent of OLE 1.0 was to allow the user to view different types of data in a single interface. Before OLE 1.0, applications were strictly monolithic. If you wanted to write a document, you would use a word processor. If you wanted to edit financial data, you would use a spreadsheet. OLE 1.0 changed that and allowed the user to view the document, spreadsheets, and charts side by side in a single application. Admittedly, this was a little awkward, because to edit a piece of data, you had to double-click the data and bring up a separate application to change it. But it was an improvement.

OLE 2.0 came along and added the concept of in-place activation. This meant the user could double-click a piece of data and, instead of launching a completely separate document, could edit the data inside the hosting application. This was a great step forward but still a little awkward. First you had to double-click the data to activate it. This was counterintuitive. Users were familiar with single-clicking something when they wanted to focus on it. Yet, despite this awkwardness, it was better than OLE 1.0.

Active documents add yet another layer to OLE. Instead of appearing inside another document, active documents occupy the entire client area of the container. It appears as though the container is the native application. This concept is very useful, particularly when you think of the Internet. A container application that can adapt itself to any document it receives is a powerful tool. This is exactly what browsing the Web is all about: exploring lots of different things and downloading lots of different documents into your browser. Internet Explorer is an example of an active document container that does just that.

Figure 26.1 illustrates the OLE architecture. Notice how the upper layers in the architecture depend, to some degree, on the lower layers. This diagram is like a historical summary of how OLE has changed. Each time the OLE specification changes, another building block is added to the existing foundation.

Figure 26.1 OLE architecture.

In this section, you will examine the various parts of the OLE architecture.

Structured Storage

Structured storage is a very interesting concept. It came about as a result of the implementation of compound documents. Not only should the user be able to view and edit dissimilar data within the same application, but the user also should be able to save all the changes to the same file. This requirement drove the need for structured storage.

Structured storage is similar to a file system. Data is stored in storage objects, which in turn can be stored in other storage objects. Storage streams that contain the real data can be stored in storage objects. This is analogous to files that reside in directories that reside in other directories.

This capability to segregate portions of one file into hierarchical partitions is very useful for documents that contain other embedded objects. Each object can be assigned its own storage area inside the file, and the embedded object can put anything it wants in its own storage area. Figure 26.2 illustrates the hierarchical nature of structured storage.

Figure 26.2 Hierarchical structured storage.

Monikers

Monikers provide a means of referencing other objects without storing the objects themselves. They are intelligent OLE objects that are the backbone of OLE linking. When you link an object into a compound document, the OLE object is referenced by a moniker. By activating a moniker, you can retrieve the original OLE object and activate it within the compound document.

Uniform Data Transfer

Uniform Data Transfer (UDT) provides a means of obtaining data from another object without being restricted to a particular transfer medium. The standard Windows Clipboard allows the transfer of data between applications using several formats. Each of these formats has to be transmitted through the Clipboard memory, however. Although appropriate for some kinds of data, UDT becomes impractical for large data sets.

Uniform Data Transfer allows several formats to be transferred between applications using several mediums. The medium could be memory, as with the Clipboard. It also could be a disk or the OLE IStorage and IStream interfaces.

Embedded Objects

Embedded objects are OLE objects that allow themselves to be embedded inside a container. Embedded objects store their data in the structured storage of the container. Microsoft Word is an example of an embedded object as well as an active document.

Linked Objects

Linked objects are OLE objects that allow themselves to be linked inside a container. Unlike an embedded object, a linked object is not stored in the structured storage of the container. Instead, a linked object contains a reference to the location of the real object. Typically, the linked object provides an iconic representation of itself inside the container. After you double-click this icon, the native application appears for editing.

Drag-and-Drop

OLE drag-and-drop provides a way for different applications to move data among themselves. Without OLE drag-and-drop, each application would have to define its own protocol by transferring data between itself and another application. OLE drag-and-drop, in combination with Uniform Data Transfer, provides a more system-wide protocol for exchanging data using the mouse.

In-Place Activation

In-place activation is a key feature introduced as part of OLE 2.0. It enables you to edit documents inside a container's client area without launching the native application. In-place activation also is called visual editing. Typically, an object that is in-place activated has some kind of hashed border around it. This indicates that the highlighted object is being worked on. Figure 26.3 shows Microsoft Word as an in-place activated object.

Figure 26.3 Microsoft Word as an in-place activated object inside Excel.

Active Documents

Active documents are in many ways just like in-place activated documents. The exception is that when you place an active document in an active document container, it takes up the entire client area of the container. Gone are the hash marks that identify an in-place activated object. You do not have to double-click the active document to activate it. It comes up active and appears to be a native application. Figure 26.4 shows Microsoft Word as an active document. Notice how the active document container appears very similar to the native Microsoft Word application.

Figure 26.4 Microsoft Word as an ActiveX document inside Microsoft Binder, an active document container.

The COM Interfaces | Next Section

Previous Section