Cafe OLE: get ready for Windows 4.0 with OLE 2.0. (object linking and embedding; includes related information the development of OLE and its future)
by Clifton Karnes

OLE 2.0 is hot off the drawing board, and it's one of the most important computing technologies of the nineties. It will help you move the focus of your work from the means you use--applications--to the end results--documents. It's also one of the cornerstones of Windows 4.0, and it will be even more important in versions of Windows beyond 4.0. Best of all, it's here now and ready to be explored. If you tried OLE 1.0 but gave up because it was too complicated, too limited, or both, don't give up on the technology. This completely new version of OLE is easier to use, more powerful, and more robust.

OLE 2.0 Defined

OLE stands for Object Linking and Embedding, and it's pronounced "oh-LAY," just like the word you'd shout at a bullfight. It's an extension of the Windows operating system developed by Microsoft that makes working in a document-centric style possible. Document-centric is a ten-dollar word which simply means that documents, rather than the programs that create them, are the focus of your work.

Think about the way you work now. You probably approach your tasks in terms of applications. If you use a word processor, a spreadsheet, and an illustration program to create documents, your work is probably organized around running each of these applications, rather than focused on the documents the applications create.

Just what does OLE 2.0 do? OLE gives you the power to do four things:

* Create compound documents containing embedded or linked objects.

* Edit embedded objects in place (this is called visual editing).

* Drag and drop objects between documents.

* Control other OLE objects with OLE automation.

First and foremost, OLE lets you create compound documents, where one document is constructed from several other documents. For example, a word-processing document can contain a table from a spreadsheet and a picture from an illustration program. But you can add spreadsheet data and pictures to a word-processing document now with the Windows Clipboard. How is this different?

When you use the Clipboard, the application into which you are pasting doesn't know anything about the application that supplied the data. With OLE, it knows what application supplied the data, and by double-clicking on the OLE object, you can call the object's creator.

OLE 2.0 also supports drag and drop between applications, so an object--such as a text selection--can simply be dragged from one OLE app (called the source) to another OLE app (called the target). As you probably know, Windows 3.1 introduced drag and drop for files, with File Manager as the only application from which you could drag; but with OLE 2.0, you can drag and drop objects between applications as well.

And OLE automation makes it possible for one program to control another. This process is something most of us won't use, but it gives programmers a powerful tool for integrating programs and designing front ends.

Think of OLE automation as a macro language that gives you access to an application's internal commands and data structures. With OLE automation you could, for example, create a Visual Basic program that would manipulate three applications: a communications program, a spreadsheet, and a word processor. It would use automation to have the communications program call an online service and download stock information. It would update the spreadsheet with this information and automatically create a report with the word processor, embedding the spreadsheet data as part of the report.

Fighting the Bull

The word OLE conjures up images of bullfighters and charging bulls, and just like a real-world bullfight, OLE has two primary players: the bull, which is the server application, and the bullfighter, which is the container application. The OLE goal is for the bull to embed his horn in the bullfighter.

In this bullfighting scene, we're the cheering, but occasionally confused, spectators. A little dose of jargon will help clear away the confusion. You've been bombarded with a little OLE-speak already, because it's impossible to talk about what OLE does without introducing some of it. Here is a short OLE lexicon. Once you learn these six terms, OLE will be much easier to grasp.

* Object

* Container

* Server

* Linking

* Embedding

* Visual editing

The most important player in the OLE drama is the OLE object. The object is anything you embed in a document or link to it (I'll explain linking and embedding later). For example, if you're working in a Word document and you include a selection from an Excel spreadsheet and a CorelDRAW! illustration, the spreadsheet and the illustration are OLE objects.

In the example above, the Word document that holds the spreadsheet and illustration is the container, the application that contains the OLE objects. The applications that supply the OLE objects to the container are called servers, so in our example, Excel and CorelDRAW! are servers. Just to keep us on our toes, Microsoft has changed the jargon a little here from OLE version 1.0 to version 2.0. Back in the days of OLE 1.0, the container was called the client (as in client/server), and you'll still hear that term used sometimes in connection with OLE 2.0.

While objects are the most important OLE element, servers--the applications that create the objects--are the most interesting, and there are two types: full servers and miniservers.

A full server is a stand-alone app that can run all by itself, like Excel, Word, or CorelDRAW!. A miniserver is an application that can't run by itself; it can only be called from a container. Microsoft Draw, which appeared with Word 2.0, is an example of a miniserver, and Word Art, which appears in Word 2.0 and Word 6.0, is another example. These applications exist only to serve containers.

Now to linking and embedding. When an object is linked, the data remains in the original file, and any changes you make to the original object's file are reflected in the linked object. If an object is embedded, the container gets a full copy of the object's data, which becomes part of the container document. If you make changes in the original file, these changes are not reflected in the embedded object.

With OLE 2.0, if an item is linked, you can double-click on it to run the server--its creator. If an item is embedded and the server supports visual editing, you can double-click on it, and the container will transform itself into the server.

The key to linking and embedding should be obvious: If you're working with a compound document, double-clicking on a linked or embedded item will summon its creator either by running the application or by turning the container into the server.

Now that we have some jargon under our belts, it's important to note that applications may support all of these OLE features or just a few. Some apps are containers only, some are servers only, and some may support everything but visual editing, drag and drop, or automation. Just knowing an application supports OLE 2.0 doesn't necessarily tell you much.

When you read in a flier or an advertisement that a product supports OLE 2.0, take the time to inquire as to which OLE features are supported. Not surprisingly, Microsoft products are among the products with the most complete OLE support.

Three-Way Paste

There are three ways to place in a document in one application an object from another application. One of them doesn't involve OLE and two of them do. The three major moves, as you might guess, are simple pasting, OLE embedding, and OLE linking.

Here's the scenario: You want to insert a CorelDRAW! 4.0 picture into Word for Windows 6.0. You have three ways to do it.

Paste. Simple pasting is the way you normally move data using the Clipboard. If the picture has already been created, copy it to the Clipboard. Then, in Word, choose Edit, Paste. This gives Word a copy of the CorelDRAW! data in a format Word can use, but there's no link to CorelDRAW!. If you double-click on this object, Word runs its own graphics editor. Word has forgotten all about CorelDRAW!.

Embed. There are three ways to embed objects, depending on the object's state. You can embed new objects, files, or selections on the Clipboard.

If the picture has already been created, copy it to the Clipboard. Then, in Word, choose Edit, Paste Special, click on the Paste option button, and choose CorelDRAW! 4.0 Object. This embeds the illustration in the Word document, and double-clicking on the object in Word runs CorelDRAW!.

To embed a new illustration in Word, choose Insert, Object, select the Create New tab, and choose CorelDRAW! 4.0 Illustration from the list box. This will run CorelDRAW! with a blank document loaded. Create your new illustration. When you've finished, select Exit and Return from the CorelDRAW! File menu, and the Corel document will be embedded in the Word document.

To embed a file in Word, choose Insert, Object, select the Create from File tab, and choose the CorelDRAW! 4.0 CDR file you want to embed. It's worth noting here that you can display your embedded object as an icon, if you wish.

Link. If the picture has already been created, copy it to the Clipboard. Then, in Word, choose Edit, Paste Special, Paste Link, Object.

To link a file in Word, choose Insert, Object, select the Create from File tab, check Link to File, choose the CorelDRAW! 4.0 CDR file you want to link, and that's it. Here, as with the example above, you can display your linked object as an icon.

To summarize these actions from another point of view:

* To paste, simply choose Paste from your application's Edit menu.

* To link or embed an object that's on the Clipboard, use Edit, Paste Special.

* To link or embed a file, use Insert, Object, Create from File.

* To embed a new object, use Insert, Object, Create New.

Drag and Drop

If you want to embed an object, drag and drop may be the easiest way to move the data between your documents. Here's the procedure you'd follow to embed a section of an Excel spreadsheet in a Word document using drag and drop.

1. Tile Word and Excel side by side on the desktop.

2. Select the cells in Excel you want to embed in Word.

3. Place the mouse pointer on the selection's border, hold down the Ctrl key, and drag the selection to Word. (When you hold down the Ctrl key and drag, you copy data from the server to the container. If you want to move data, simply drag it, or hold down the Shift key and drag.)

It's worth noting that when you drag and drop, the selection doesn't go through the Clipboard, so you can't paste another copy somewhere else without either dragging and dropping again or going through copying and pasting with the Clipboard.

You can edit the object you've used drag and drop to embed the same way you would edit any other embedded object: by double-clicking on it.

Multiple-Choice Test

Now that you understand the differences between pasting, linking, and embedding, you may be wondering about the benefits of one versus another. Here are some guidelines.

If the object is very large, link it. In a linked object, the object's data stays in the original file, so it doesn't increase the container document's size.

If the original file will change over time, and you want the changes to be reflected in the object, link the object. Since a linked object's data stays in only one place--the file--the container's link always reflects the latest version of the file.

If the file is used in several places, and it needs to display the same data in each place, link the object.

If the object needs to be transferred and read by someone who doesn't have access to the original file, embed the object. When you embed an object, the container gets a complete copy of the object's data.

If there will never be a need to edit the object again with its creator, simply paste it.

Linking is often more useful than embedding. The downside with linking is that, if the linked file moves, your link is broken and must be repaired. Since an embedded object becomes part of the container document, you never have to worry about broken links.

OLE Automation

One of the most exciting things about the new OLE specification is OLE automation, which lets you use one program to control objects in another program. Visual Basic and Excel's built-in Visual Basic for Applications are both OLE automation drivers. They can't control just any program, however. The programs you control must be written in such a way that certain features are exposed to other applications. Each OLE application must decide whether it will support automation at all, and if it does, which of its functions it will make available to other applications.

At the time of this writing, very few programs support OLE automation, but this is bound to change.

OLE Servers and Containers

Now you're probably ready to try some linking and embedding yourself. You may be surprised at the number of OLE applications already on your system. Unless you have recent versions of Word, Excel, CorelDRAW!, and a handful of others, these are probably OLE 1.0 apps, but OLE 1.0 is still useful, and the two versions of OLE work together without conflict.

To find the OLE servers you have installed on your system, run Windows Write (or any application that's an OLE 1.0 or 2.0 container) and select Edit, Insert Object. You'll see a dialog box with a scrolling list of all your OLE servers. The list will include both OLE 1.0 and OLE 2.0 servers, but the two are completely compatible. With OLE 1.0 you can do most of the things you can with OLE 2.0, except visual editing, drag and drop, and automation.

When you look at this list, you may also discover that you have several servers listed that you've removed from your hard disk. How do you remove these from the list? It's relatively easy. This list comes from something called the Registration Database. When an OLE 1.0 or 2.0 application runs for the first time, it registers itself in the database so other apps can find it.

To delete an entry in the database, run the Registration Database by choosing File, Run from Program Manager or File Manager, typing regedit.exe in the Command Line box, and pressing Enter. Look in the Registration Database's list box to find the application you want to delete. Then select it and choose Edit, Delete File Type from the menu.

While it's fairly easy to find all the OLE servers on your system, there's no one place you can look to see all the OLE containers. However, any application that has an Insert Object menu option is almost certainly a container.

To find out if your application supports OLE drag and drop, simply try it. As for OLE automation, you'll have to check out the application's documentation to see whether that feature is supported and if it's supported, which of its functions are available.

Building OLE 2.0 Apps

Creating OLE applications used to be a programmer's nightmare. The OLE 2.0 API (Application Program Interface) is huge, and there are literally thousands of details to keep track of. But two programming tools have changed the nightmarish aspects of OLE programming. The first is Visual C++ 1.5. This version of Microsoft's superb integrated development environment adds OLE classes to MFC (Microsoft Foundation Classes), and it adds OLE creation to App Wizard. Creating a container, full server, or miniserver is almost as easy as choosing these options from the App Wizard dialog.

The second programming language that's made OLE 2.0 approachable is Visual Basic 3.0. With it, you can create OLE 2.0 containers and use automation. (There's no support for creating servers, however.) If you want to start experimenting with creating OLE 2.0 applications, Visual Basic 3.0 is the place to go. Its documentation also contains an excellent overview of OLE 2.0.

The Good, the Bad, the Ugly

We've seen a lot of the benefits of OLE, but there's a downside, too. There are three primary disadvantages to OLE: broken links, large files, and big memory requirements.

Broken links occur when you move a linked file. If this happens, most containers have a way for you to manually repair the link, but it's a pain. The next version of OLE should do a better job of tracking links.

If you embed objects, your files can quickly become huge--easily several megabytes. Not only do these files take up lots of disk space, but they eat up RAM as well when you're working with them.

And speaking of RAM, when you edit an OLE object and run its server, both container and server must be running at the same time. With programs the size of Word and Excel, I'd consider 8MB of memory a minimum to accomplish this.

But the dramatic benefits of OLE really overshadow these problems. In the final analysis, OLE is the most powerful way to share data between applications today. And since you're going to be seeing more and more applications that offer OLE features in the future, now's the time to take the bull by the horns and begin linking, embedding, dragging and dropping, visual editing, and automating.

How We Got Here: Clipboard, DDE, OLE 1.0, and OLE 2.0

Despite its novelty, OLE 2.0 is not revolutionary, but the product of evolution that began with the humble but amazingly useful Windows Clipboard.

The Clipboard is the first means Windows users had of sharing data between applications. In many cases, it's all you need. You simply press Ctrl-C to copy and Ctrl-V to paste, and that's it.

Next came DDE, Dynamic Data Exchange, a precursor to OLE automation. With DDE, one application could control another and move data back and forth. As anyone who's programmed DDE can tell you, however, it's hairy. DDE connections are easily broken, and behavior is not always what you'd expect. DDE has proven popular and useful, however.

Next on our list is OLE 1.0. This first pass at OLE gave us the power to keep a connection between data pasted into an application and the data's creator. Through this link the data is automatically updated when the original is changed, and you can run the object's creator by double-clicking on the object.

OLE 2.0 carries everything in OLE 1.0 a big step further. With 2.0, you can not only double-click on an OLE object to call its server application, but if the object is embedded, your container will transform itself into the server. OLE 2.0 also adds object drag and drop between applications, and OLE automation, which will probably replace DDE.

Windows 4.0 and Beyond

OLE is one of the cornerstones of Windows 4.0, and Microsoft is urging all developers to make their apps OLE compliant. In 1995, programs that don't support OLE will be the exception rather than the rule.

Although OLE 2.0 is being used now primarily as a way of creating compound documents that are easy to work with, in the future the container-server model will be extended to applications as well. In this just-around-the-corner version of OLE, applications will be constructed from containers populated with components, which are small, focused miniapplications. This extension of OLE is called the component-object model, or COM.

As an example of COM, you could build your own word processor with the container engine from one vendor, the spelling checker component from another, the thesaurus component from another, and the graphics component from another.

You could also build your own PIM by putting together components from various publishers to create an application with just the features and functionality you need.

OLE also contains its own built-in file system, and in the future files may be replaced by OLE objects. These OLE files will know about themselves, and they'll know how to communicate with other OLE objects. They'll be able to export themselves in various formats and make information about themselves public.

In fact, it may not be long before everything on your Windows desktop is an OLE object. When this happens, we'll have a really intelligent operating system. I just hope the price of RAM goes down then, so OLE objects will have enough room to think.