Associations, Linkages, and OLE-How Confusing Can This Get?

Overview

OLE (Object Linking and Embedding) is a technology that allows applications to share data and functionality easily. I like that. Sounds good. It's quick and easy to understand, and it's basically accurate. Using OLE, applications can pass data back and forth, and OLE also allows a server and client to pass programming functionality between them. The server is able to do something that the client wishes done.

OLE works extensively with the registry. But before we get to that, it's important to understand how OLE evolved and how it functions.

Understanding OLE (or Not) First, let's start out with a few ground rules:

• There is no way to learn all about OLE in one chapter. (I doubt you could learn all about OLE in a single book!)

• Even OLE experts are not really experts.

• There are a number of good books on OLE, but unless you are programming, avoid them.

• If you don't understand everything about OLE after reading this chapter, don't feel bad.

• The author takes no responsibility for what happens when you wake up at 2 A.M. and shout, "Now I understand!"

Most programmers don't build their OLE applications from the ground up. Instead, for the difficult parts, they use development systems such as Microsoft's Developer Studio. Today, a programmer can create an OLE application almost as quickly as any other type of application.

Most applications manage their initial OLE setup by themselves. Some applications rely on their installation programs to do the OLE setup. And some applications use the installation program both to set up OLE and, if the configuration becomes damaged, to repair the damage to the extent that they can reconfigure the OLE components.

This brings up some questions. First, how does OLE work? Second, what does OLE have to do with the registry? Moreover, why do we have to worry about it? Do we mention DDE?

And where, oh where, does the Clipboard fit into this mess?

OK, stay tuned for answers to all of these questions.

Introduction to OLE

Kraig Brockschmidt of Microsoft is probably the best-known expert on OLE. Here's how he describes its evolution:

Windows API (Application Program Interface) evolved into Windows Objects, which eventually became what we know as OLE.

Kraig admits it's not that simple, but OLE developed by evolution, not by revolution.

Way back in the good old days, Windows was much simpler and easier to understand. In its first incarnation, Windows allowed virtually no interprocess communications. There was the Clipboard (which we still know and love), to which one program could post data that another program could (hopefully) read. However, that exchange required user interaction. The user was required to take steps to put the selected data on the Clipboard and then in the recipient application take steps to retrieve the data stored in the Clipboard.

Problems arose. First, the basic Clipboard supported only a very limited range of data types.

Programs could exchange data in various basic formats (text and binary, for the most part), but these formats were sorely lacking the flexibility to express any object that was composed of compound data.

Compound Data?

Compound data is data that contains information in multiple formats. The easiest type of compound data to envision is a word-processing document that includes some images. At this point in the evolution of the Clipboard, the word-processing program couldn't just toss that document and its images on the Clipboard. After all, how would the program identify the format of that data? If it said binary, no other application would be able to understand or use the data. If it said text, what would happen when an application tried to use the data and encountered the images? Would it delete the images? Sure, that would work, but if the user

wanted the complete document, including the images, he or she would be most unhappy about the results.

Microsoft realized quickly that applications needed a direct, application-to-application communication method that didn't rely on the Clipboard. Quickly or slowly, depending on your point of view, the concept of DDE (Dynamic Data Exchange) was born. Actually

"conceived" would be a better description, because DDE wasn't viable in its original format.

As it grew, DDE did allow applications to communicate data. However, there were still problems. With DDE, there was no way for applications to find out about their partners.

Developers created most DDE applications specifically as pairs. For applications from two independent sources, DDE was unlikely to be useful, because the developers would have to cooperate in order to take advantage of DDE.

OLE became the next stage in the development of interapplication communications and data sharing. OLE allowed an application to interact with another one without knowing, in advance, about the other application. Magic, really.

The Clipboard

The Clipboard is the original and most basic method to transfer data between applications.

The Clipboard supports both inter-application transfers (between two applications) and intra-application transfers (within the same intra-application).

There is only one object in the Clipboard at any one time. (Microsoft Office uses a multiple document Clipboard interface; however, this interface is created and implemented by Office, and not Windows.) There are some complex rules on the Clipboard, such as the following:

• An application cannot assume that an object placed in the Clipboard will remain there after the application releases the Clipboard. Therefore, it is not possible to use the Clipboard as a temporary storage location.

• The format of the object in the Clipboard must be in one of the standard formats (listed below), or the application placing the data on the Clipboard must be prepared to render or display the Clipboard's contents.

• Some objects in the Clipboard are in a format that is not native to Windows. These objects require the application that places the object to be available to display or render the object if necessary.

Windows XP supports the following types of data in the Clipboard, without creating custom formats:

CF_BITMAP A bitmap (image)

CF_DIB A DIB (Device Independent Bitmap)

CF_DIBV5 A version 5 bitmap (available on Windows 2000 and later versions) CF_DIF A DIF (Data Interchange Format) object

CF_DSPBITMAP A private format bitmap

CF_DSPENHMETAFILE An enhanced metafile display format object CF_DSPMETAFILEPICT A metafile-picture display format object CF_DSPTEXT A text display format object, with private format CF_ENHMETAFILE An enhanced metafile object

CF_GDIOBJFIRST through CF_GDIOBJLAST A range of integer values for application-defined GDI (Graphical Device Interface) objects

CF_HDROPV A handle of type HDROP, identifying a list of files CF_LOCALE Locale information

CF_METAFILEPICT A metafile picture object

CF_OEMTEXT A text format in the OEM (original equipment manufacturer) character set CF_OWNERDISPLAY An object of owner display format

CF_PALETTE A color palette object

CF_PENDATA An object containing data for the pen extensions to the Microsoft Windows for Pen Computing

CF_PRIVATEFIRST through CF_PRIVATELAST A range of integer values for private Clipboard formats

CF_RIFF A sound object too complex for the CF_WAVE format CF_SYLK An object in Microsoft Symbolic Link (SYLK) format CF_TEXT A plain-text format object

CF_WAVE An audio object, using PCM (Pulse Code Modulation) CF_TIFF A Tagged Image File Format object

CF_UNICODETEXT A text object using the two-byte Unicode character set

As this list shows, Windows supports many different formats, without any programmer intervention. However, in many situations, these formats are not adequate. In these cases, the application serving (placing) the data on the Clipboard may register a new format with

Windows. To enable viewing of the Clipboard data, you must also have code that displays the Clipboard data.

DDE

DDE, or Dynamic Data Exchange, has been part of Windows since the early days. An Excel spreadsheet (the client) for managing stock market information is an example of DDE. A second software application that actually retrieves the stock prices (quotes) is the server. In addition, another application goes to the Internet and gets current stock market quotes (the server). The two programs need to interact dynamically (after all, prices change), so using the Clipboard is not optimal; you want your spreadsheet updated dynamically and efficiently, without any user interaction.

Through a process of broadcasting, Excel (the client) establishes a communications link with the server. Excel broadcasts its request and the server responds that it is able to fulfill this request. A DDE linkage is established, allowing Excel to request information from the server as necessary.

As an example, you may be interested in a particular list of stocks. Excel would tell the server to check these stocks and provide the current quote for them. Excel might also have a timer loop that repeats this process every five minutes, providing you with up-to-date stock quote information.

As another example, you might request a one-time quote on a stock of interest. Maybe you're interested in just how well Microsoft (MSFT) is doing on the stock exchange. Perhaps your spreadsheet has a section where you type in the stock name. You enter the name, and the quote comes back.

Either the client or the server can perform automatic updating. Client-initiated updates might occur on a time-based basis, or when the user makes a change if the data retrieved was relatively static. Servers might initiate an update whenever the server recognizes that the information the user is requesting has become out of date.

OK, no one said DDE was easy. If they did, they didn't tell the truth. DDE is complex and very difficult to understand or use. Programmers exposed to DDE shuddered and desperately searched for better alternatives. Some programmers kludged together broadcast messages to pass simple data, but for many, DDE was still the best (only) method to exchange data between two applications.

Why Is It Difficult to Exchange Data?

Memory protection causes most of the problems; one application cannot access memory objects belonging to other applications.

When an object is placed in the Clipboard, the memory that the object occupies is given to Windows. From that point onward, Windows owns the object, and the application that placed the object in the Clipboard loses control of the object. This means that whenever an object is placed in the Clipboard, the application will usually make a copy of the object and place the copy in the Clipboard, keeping the original object for the application's use.

The DDE process uses the Clipboard to transfer large blocks of data, too. Typically, the server application places the data on the Clipboard and uses DDE to tell the client application about the data. Server applications are able to pass small data objects to the client application as part of the DDE conversation.

What Is OLE?

OLE means Object Linking and Embedding. That says it all. With DDE, and with the Clipboard, applications only pass data and do not pass any functionality. With OLE, we expand on what the server application can do for the client.

As I mentioned earlier, applications can pass both data and programming functionality back and forth using OLE. The client can request action from the server. However, the client program's developer does not have to develop all this functionality if it exists already.

As an example, take the e-mail client called Outlook. Outlook has a simple, built-in e-mail editor. However, some users want (demand, actually) more functionality in their e-mail editors. They want formatting, macros, even included images, and other nifty stuff. They want the functionality of Microsoft Word to create their e-mail.

Wouldn't it be nice if the Outlook development team could borrow part of Word? Now, it would make little sense for the Outlook development team to sneak into the Word group's office and steal the code for Word. After all, they'd then have to maintain it, and Word's one big puppy-major maintenance blues there.

What's the next best thing? First, let's let the Word developers continue to maintain Word.

Second, let's get Word to work for us. We know that the developers on the Word team

included OLE server technology into Word; Word has client OLE technology too, in case you wondered. However, we find that the Outlook team can't really expect the Word team to put special stuff into Word for them, so what can they do?

Things are not so bad here: because Word is an OLE-compliant application, all Outlook has to do is to ask Word, "What can you do for me?" Outlook does this by first checking with the server at the most basic OLE level (a level that all OLE applications must support). This level allows the client to ask the server what functionalities are supported.

Realize that when we talk about supported functionalities, we are not talking about "Do you support italic text?" Rather, we are asking such questions as "Do you support embedding?" or

"Do you support automation?" The server is then able to tell the client exactly what it is able to do. In the case of Outlook using Word to edit e-mail, Outlook asks, "Can you be

embedded?" and Word responds, "Yes, I can."

Note You might ask, "Peter, why are you are adding yet another term, OLE automation?"

This process allows the client application to take control of the server, and it lets the server see the client as a user. The client is able to actually click buttons and otherwise interact with the server application.

Now read on.

Embedding

With embedding, an object (which could be either a data object or server functionality) is embedded into the client application or the client application's data. When you embed Word into Outlook, you create a window, and using OLE, you tell Word to use this window to interact with the user. You also tell Word how it should appear to the user; for example, Outlook customizes Word's toolbars.

This embedding works regardless of whether Word is running or not. If Word is running, anything that Word is currently doing is unaffected by having Word embedded into Outlook's e-mail editing system. In fact, the OLE server treats these as separate instances of the

program, and keeps them separate. There are advantages, however. If the server is already running, it is not necessary to load a second copy of the server. Instead, the two instances share the executable code.

With embedded objects, the client owns a private copy of the object. The server may update the client's object, though the server won't change any other instances of the data.

Each time an embedded object is used, there will be a new copy of the object. For complex objects, graphics, and so on, this can consume substantial system resources.

Object Linking

Object linking is a mysterious technology where one application creates an object used by another application later. A linked object remains the property of the creating application, and there is only one copy of the object.

The server is the creating application. The server links to the client application. When the server updates the object, the client gets a message and updates the object display in the client as necessary. Some objects are not visible, so there is no display update necessary.

The closest thing to showing how linking works is to look at Windows itself. There are a number of icons on your Desktop. Most are called shortcuts, which are denoted by that funny up-pointing arrow image in the lower-left corner. Think of these shortcuts as links. Open the properties for a shortcut and go to the Shortcut tab. In the Target edit box, you will see the name of the file that is associated with this shortcut (link). If you have a dozen shortcuts to the same file, each shortcut will open the same copy of the program. There won't be a dozen copies of the program.

OLE Controls, a.k.a. ActiveX

In the previous examples, the server application was a typical Windows program.

Applications like this are native Windows applications. For example, Word for Windows is a server application. Word has a user interface and it runs on its own, without needing any client to embed the Word object.

Sometimes the server application doesn't have a native, stand-alone mode. That is, such an application doesn't have a user interface-no window, no direct way for the user to interact with the program. Applications like this are ActiveX controls; they used to be called OLE

controls. ActiveX controls are commonly used with programs such as Internet Explorer and other web browsers; however, many programs can use ActiveX controls.

Note An ActiveX control must be embedded and may never be run alone.

A typical user could have a large number of ActiveX controls installed, and the user might never know it. It is common for a user to download ActiveX controls from the Internet without ever realizing that this has happened.

VBX, What's a VBX?

VBX controls, or Visual Basic controls, were the first generation of ActiveX controls. When VBX controls were first developed, they served in dialog boxes as custom controls, things such as progress bars, and so on.

Generally, a VBX control doesn't handle data, while an ActiveX control might. In addition, only Visual Basic was able to easily create VBX controls. Programmers who developed in C/C++, for example, had difficulty creating their own VBX controls. However, Microsoft eventually developed a system to create VBX controls using development platforms other than Visual Basic.

Microsoft also realized that the concept of VBX (embeddable controls) was a good one, and that these controls were here to stay. In came the OCX (OLE Control) technology; it was development-platform independent, usage-platform independent, and more flexible.

Evolution and the name game reared their heads again. Microsoft moved to ActiveX controls more as a change in name than in function. It is common to see ActiveX controls referred to as OCX controls, and vice versa.

Some ActiveX controls display data. Some don't do anything other than provide some form of user interface. For example, these controls were on one of my computers:

• BtnMenu Object

• CarPointProximityCtrl

• ChatShowClt Object

• DirectAnimation Java Classes

• HHCtrl Object

• Internet Explorer Classes for Java

• IPTDImageControl.Slmage

• Label Object

• Microsoft MSChat Control Object

• Microsoft Search Settings Control

• Microsoft XML Parser for Java

• PopupMenu Object

• Win32 Classes

All of these controls were installed in the %SystemRoot%\Occache directory. If you are not using Internet Explorer or are not active on the Internet, you probably won't have many of these controls.

Note If you don't find an Occache directory, don't panic. It is probably because you don't have any ActiveX controls installed on your computer!

Liar, Liar, Pants on Fire!

Remember when I said previously that OLE controls don't have a user interface? Well

actually, I lied a little. It is possible to use RunDll32 to execute some OLE controls. RunDll32 doesn't have a user interface either, and any control that works with RunDll32 must be written specifically for this type of usage. For example, the OLE Active Movie control will run with

actually, I lied a little. It is possible to use RunDll32 to execute some OLE controls. RunDll32 doesn't have a user interface either, and any control that works with RunDll32 must be written specifically for this type of usage. For example, the OLE Active Movie control will run with

Dans le document Mastering Windows XP Registry (Page 116-138)