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

  • Article

By Peter D. Hipson

Chapter 6 from MasteringWindows 2000 Registry, published by Sybex, Inc.

First, let's start out with a few ground rules:

  • There is no way to learn all about OLE in one chapter.

  • 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 both use the installation program to set up OLE and, if the configuration becomes damaged, repair the damage to the extent that they can reconfigure the OLE components.

This brings up some questions. First, what is OLE? 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.

On This Page

Introduction to OLE
Client-Server OLE Applications
How Linkages Are Made between Applications
Hints and Kinks from the Experts

Introduction to OLE

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.

Kraig Brockschmidt 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, and another program could then (hopefully) read that data. However, that interaction required user interaction. The user was required to take steps to put the selected data in the Clipboard, 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 interapplication transfers (between two applications) and intra-application transfers (within the same application).

There is only one object in the Clipboard at any one time. 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 2000 is able to support the following types of data in the Clipboard, without creating custom formats:

  • CF_BITMAP: a bitmap (image)

  • CF_DIBV: a DIB (Device Independent Bitmap)

  • CF_DIBV5: a version 5 bitmap (only available on Windows 2000)

  • 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, there are many situations in which 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, it will be necessary to also have code that will display 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, there is an application that 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 would place the data on the Clipboard and use 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 passed data and did not pass any functionality. With OLE, we expand on what the server application is able to do for the client.

Not only may applications pass data back and forth using OLE, but OLE also allows the server and the client to pass programming functionality between them. The server is able to do something that the client wishes done. 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 system 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. Microsoft Word actually would do everything that the user wants.

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 we embed Word into Outlook, we create a window, and using OLE, we tell Word to use this window to interact with the user. We 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, there is a private copy of the object that the client owns. 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 our 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 create VBX controls. Programmers who developed in C/C++, for example, had difficulty creating their own VBX controls. However, Microsoft eventually did develop a system to create VBX controls using development platforms other than Visual Basic.

Eventually, Microsoft 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 there are not 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 the command:

%systemroot%\System32\rundll32.exe amovie.ocx,RunDll

This will open the Active Movie OLE control (RunDll provides a main window for the control), and Active Movie will then display an Open File dialog box. You might select an Active Movie file (try clock.avi in the Windows 2000 %systemroot% directory) and run it using amovie.ocx. This is possible because Active Movie was written to work with RunDll, and as such, it works. Try this trick with most any other OLE control, and you will get the message, "Missing entry point RunDll," which indicates that the entry point passed in the command was not found.

Oh, yes, you can also pass parameters to your OLE control with the command:

This command would load Active Movie, load clock.avi, and allow the user to interact with the control. Try it. Better yet, try this:

Don't mistakenly insert spaces between the executable file (amovie.ocx in the previous example), the comma, and the entry point (RunDll in the previous example). This will break RunDll without telling you why it failed.

Get the hint? We passed a parameter to the Active Movie control to play the clock.avi file, then to close it when the .avi file is finished. Active Movie loaded the file specified, played the file, and closed it—all without user intervention.

Oh, don't blame me if the clock.avi file is a bit annoying.

Actually, RunDll will run more than OLE controls—RunDll will (or will at least attempt to) execute any executable file, including DLL (Dynamic Link Library) and EXE (executable) files. This is true as long as you know the file's entry point and the file to be executed follows the RunDll protocol. For more information, see Microsoft Knowledge Base article 164787, which can be viewed at https://support.microsoft.com/default.aspx?scid=kb;en-us;164787&sd=tech. Though originally written for Windows 95/98, it contains information helpful to Windows 2000 users.

Client-Server OLE Applications

Client-server OLE applications make up a substantial number of programs on most Windows computers. Even though the user may not be aware of what client-server OLE applications are installed, there are many.

One of the best-designed and best-integrated sets of applications is Microsoft Office, currently released as Office 2000. It combines word processing (Word 2000 for Windows), spreadsheets (Excel 2000), a database system (Access 2000), a presentation program (PowerPoint 2000), and a host of utilities (such as Chart). Each of the main applications in Microsoft Office works as both a client and a server application. Some applications—such as the Word Art and Chart utilities—are not designed to run as simple clients. For example, take Word 2000 (a program that at least I know how to use).

Word, as a client is . . . Word. Open Word and edit a document. Write a short letter to someone, it doesn't matter whom. Create something, about a page long, three or four paragraphs. You have Word's functionality in all these paragraphs; you did everything using Word and nothing else.

Now things start to get exciting. Insert an object. For grins, insert a drawing into a Word document. Click Insert „ Object. Word displays the Object dialog box that lists all the embeddable OLE server objects (see Figure 6.1). Actually, OLE uses an API call to display the dialog box.

Figure 6.1: Inserting a Microsoft Clip Gallery object is as easy as selecting it from the Object dialog box.

Some servers work by totally embedding themselves into Word. For example, Microsoft Paint will replace Word's menu with the Microsoft Paint menu and display the Microsoft Paint tool bars and so on—all without any user intervention (whammo, check out Figure 6.2).

It is quite incredible that Microsoft Paint works without Microsoft Word having prior knowledge of it. Actually, select a Microsoft Paint object and Word gives control to Microsoft Paint. Microsoft Paint then displays its own menu items along with Word's Window menu so that the user can switch between Word documents if necessary—just like I'm doing while I write this chapter.

When the Microsoft Paint object is not selected, Word takes control of the user interface, and the Word menu structure is restored (see Figure 6.3). You do context-switching between Word and Microsoft Paint whenever you select something in the document. If you select something from Microsoft Paint, Microsoft Paint is put in control; otherwise, Word takes control.

Figure 6.2: Microsoft Paint gives the user a new menu, new toolbars—it just plain takes over.

Figure 6.3: Microsoft Word restores its own menu and toolbars when Microsoft Paint is _not active.

There's a lot of magic going on behind the scenes here. When saving a complex document containing OLE objects, the objects' servers save the OLE objects when and where instructed to do so by Word.

Oops, topic-drift. I'm trying to make everyone an OLE expert. Let's see if we can wrap this up in a nutshell, then connect everything with the registry.

So, in a nutshell:

  • Client applications may have OLE objects embedded into their documents, and/or have OLE server functionality embedded into their basic functionality.

  • This embedding is done at runtime, so the developer knows nothing about what embedding will be done when the program is being written.

  • When a client application wants to embed an OLE object, the client application will call OLE to display the Insert Object dialog box to the user. The user then selects the embedded object.

  • By selecting the object, OLE allows the client's user interface (menus and toolbars, for example) to be turned over to the server application.

  • Server applications may edit the object in place, or may create a special editing window, which may have menu/toolbar support, as appropriate. Usually, complex objects have their own windows for editing just to keep things simpler for the user.

  • OLE uses the registry to learn about embeddable server applications.

  • OLE server and client applications are identified by CLSIDs; call 'em UUIDs, or GUIDs, if you want. A CLSID is a unique long string of numbers.

  • The server application is able to use OLE to tell the client what capabilities the server has. This allows the client to behave in a predictable manner.

Note: It is possible to embed a purely functional OLE object into a document. From time to time with database programming, OLE controls (ActiveX) and OLE applications (without instance-specific data, such as Microsoft Comic Chat) are used.

OK, I've prattled on about OLE long enough (is that a wild cheer I hear?), so let's get to the registry component of OLE.

OLE and the Registry

Wow, now we're back to the registry. That was a lot of stuff to cover, just to get a handle of the basics of OLE.

OLE works extensively with the registry. When an application registers itself with OLE as a potential server application, this registration process consists of adding a number of entries into the registry. For OLE applications, such as ActiveX controls, these entries are relatively simple and easy to follow. More complex OLE applications, take Microsoft Word as an example, have hundreds of entries in the registry and are typically difficult to understand.

Let's look at a simple OLE control—the ActiveX control called the Comic Chat control. Comic Chat is an application available from Microsoft to allow users to use the Internet chat facility. There are hundreds of chat servers—try chat.msn.com, chat.microsoft.com, or any other IRC chat server. Chat can be fun.

Yes, Comic Chat is embeddable into a Word document. This usage, though not typical, is legitimate. Check out Figure 6.4 to see Word and Comic Chat working together. In the session that I used for this figure, I actually was chatting with two computer users in Australia and one user in North Carolina in the U.S.

Figure 6.4: Embedding Microsoft Comic Chat adds a new dimension to your Word documents.

Size and Placement…

Some versions of ActiveX controls, such as Comic Chat, don't work well when embedded into Word. They do not properly size themselves and tend to resize their display in unexpected ways. This is not acceptable behavior, I might add.

In Comic Chat's case, the control creates a base window, and then sizes the main Comic Chat window to fit the base window. Unfortunately, when a user tries to resize the Comic Chat window, Word restores it to the size of the underlying base window.

One way to resize Comic Chat is to first make it smaller, then quickly before Word resizes it, click on the underlying base window. This locks the base window, and then you may resize it as appropriate. Once satisfied with the Comic Chat window size, a simple double-click anywhere inside the base window will restore the normal display.

Microsoft Comic Chat is a large application that doesn't allow a lot of interaction with other documents or other applications. Nevertheless, why would you, a user, want other interaction? Easy! One, classic example is to embed Comic Chat into a Web page, a document whose application is the Web browser. Another example is to embed Comic Chat into an e-mail message. Ding! Did the light go off? E-mail everyone on your team and include in the message the details of a virtual meeting both on an IRC chat server and on the client.

So, we have a Microsoft Comic Chat OLE server application implemented as an ActiveX control. Let's look at the registry entries for Comic Chat.

First are the entries in HKEY_LOCAL_MACHINE \Software \Classes \CLSID. These entries define much of the OLE interface:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}]

@="Comic Chat Room"

The lines above are the hive (HKEY_LOCAL_MACHINE), key (Software), and subkeys (Classes\CLSID), followed by any values that these keys might contain. A value in the form of @=data denotes the default value entry found in every registry key and subkey.

Note: The Windows 2000 CLSID is identical the Windows NT 4 CLSID. Surprised? Don't be, as the CLSID comes from the application, not the operating system. Also, Comic Chat version 2.1 has the same CLSID as Comic Chat version 2.5.

The first subkey contains the CLSID for the Comic Chat server. This CLSID happens to be 241AF500-8FB6-11CF-ADC5-00AA00BADF6F, although other versions of Comic Chat might have different CLSIDs. The default data variable contains a string describing the program. Notice that this string is also found in the second section of the registry, HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1, described next.

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\AuxUserType

@=""

Windows uses the AuxUserType subkey for short, people-readable names for the application. Menus, both regular and pop-up, use these short names. Microsoft recommends that the names in AuxUserType be limited to not more than 15 characters.

This example shows one name for the application—the string Room:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\AuxUserType\2

@="Room"

This example shows another name for the application—the string chat:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\AuxUserType\3

@="chat"

Take this entry:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\DefaultExtension

@=".ccr,Microsoft Chat Room (*.ccr)"

In this entry, the DefaultExtension subkey holds the suggested extension (file type) for the default when File Save As or File Open is selected in the menu.

Take this next entry:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\DefaultIcon

@="C:\\PROGRA~1\\MICROS~2\\CChat.exe,1"

In this entry, the DefaultIcon subkey holds information about the icon. This icon is an icon index in the executable file listed. Though the executable file containing the icon need not be the same executable file as the OLE control, it is good if it is.

The following entry, which works with the Microsoft OLE DocObject technology, can contain information about the capabilities of the OLE object:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\DocObject

@="0"

In the next entry, the InprocHandler32 subkey tells the system what in-process handler will be used.

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\InprocHandler32

@="ole32.dll"

Many applications use Ole32.dll as their in-process handler, although this is not a requirement. Another commonly used in-process handler is MAPI32.DLL, which is used by many mail-enabled objects:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\Insertable

@=""

Intended for use with Windows 95/98 and/or Windows 2000, the following entry indicates to the system that the application is listed in the insert list of the Insert New Object dialog box:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\LocalServer32

@="C:\\PROGRA~1\\MICROS~2\\CChat.exe"

The next entry contains the application's fully qualified path and executable filename. This string is not a REG_EXPAND_SZ, so don't use substitution variables:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\MiscStatus

@="32"

Table 6.1 lists the flag values allowed in MiscStatus.

Table 6.1 Flag Values Used in the MiscStatus Object

Flag (Value) in Decimal

Flag (Value) in Hex

Description

1

0x0001

When resizing, the object is recomposed.

2

0x0002

The object is only available as an icon.

4

0x0004

The object is used in insert mode, not replace mode.

8

0x0008

The object is static.

16

0x0010

The object can't link inside.

32

0x0020

OLE 1 can link the object.

64

0x0040

The object is a link object.

128

0x0080

The object is inside out.

256

0x0100

Activate the object when it is visible.

512

0x0200

The object's rendering is device independent.

Note: In MiscStatus, combine values using binary or bitwise addition; the easiest way to do a bitwise is to simply add the values. For example, an application with the flags "OLE 1 can link the object" (32) and "Activate the object when it is visible" (256) would store a value of (256 + 32) = 288 in MiscStatus.

In this entry, the Printable subkey denotes an OLE object that will support the IPrint method:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\Printable

@=""

For an insertable object, there must be an associated ProgID value (ProgID is shorthand for "programmatic identifier"). This value consists of a short name, a type, and a numeric value:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\ProgID

@="ComicChat.Room.1"

A registry section is created with this name (see the next entry), where more registry values will be stored for this object:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\Verb

@=""

Verbs indicate types of action that the object may take. Always numbered consecutively in the registry, there are three components to verb entries, as shown here:

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\Verb\0

@="&Edit,0,2"

This sample verb, Edit, shows three things. First, the text used in the menu, &Edit. The & indicates that the letter following it will be underscored and used as a hotkey value.

Second, the first number, 0, is the menu flag's value. Shown in Table 6.2 are the valid values. (Not all are used with OLE menus, such as MF_OWNERDRAW.)

Table 6.2 Flag Types Allowed

Flag Name

Value

Description

MF_STRING

0x000

The menu item is a string.

MF_ENABLE

0x000

The menu item is enabled.

MF_UNCHECKED

0x000

The menu item is unchecked.

MF_INSERT

0x000

The menu item is an inserted item.

MF_BITMAP

0x004

The menu item is a bitmap.

MF_CHECKED

0x008

The menu item is checked.

MF_DISABLED

0x002

The menu item is disabled.

MF_GRAYED

0x001

The menu item is dimmed.

MF_OWNERDRAW

0x100

The menu item is an owner-draw item.

Third, the second number, 2, is the verb flag. There are only two possible values for this entry, as shown in Table 6.3.

Table 6.3 Verb Flag Names

Verb Flag Name

Value

Description

OLEVERBATTRIB
_NEVERDIRTIES

1

Indicates that the verb does not modify the object, so the object will not require storing in persistent storage.

OLEVERBATTRIB
_ONCONTAINERMENU

2

Indicates that the verb should appear on a pop-up menu.

There is a second section of the registry for the Comic Chat OLE object. This section, in HKEY_LOCAL_MACHINE \Software \Classes, is called ComicChat.Room.1.

In the ComicChat.Room.1 subkey, there are two value entries:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1]

@="Comic Chat Room"

"EditFlags"=hex:00,00,01,00

The first value entry is the default value (@=) that contains the name ("Comic Chat Room") used in the insert list of the Insert Object dialog box. The second value, _EditFlags, contains the edit flags, expressed as hex values:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\CLSID]

@="{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}"

The CLSID subkey contains the object's CLSID.

The next subkey, which works with the Microsoft OLE DocObject technology, may contain information about the capabilities of the OLE object:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\DocObject]

@="0"

Intended for use in Windows 95/98 and/or Windows 2000, the following entry indicates to the system that the application should be listed in the insert list of the Insert New Object dialog box:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\Insertable]

@=""

The protocol subkey is used for compatibility with OLE 1 container (client) applications:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\protocol]

@=""

There is one subkey in protocol, called StdFileEditing. Within StdFileEditing, there are a number of items, as shown here:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\protocol\_StdFileEditing]

@=""

The default entry in StdFileEditing is an empty string.

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\protocol\_StdFileEditing\server]

@="C:\\PROGRA~1\\MICROS~2\\CChat.exe"

The first subkey in StdFileEditing is the server subkey. Inside server is the default string that contains the fully qualified name of the server executable file. Becauses this string is REG_SZ, do not use any substitutable variables, such as %systemroot%, in it.

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\protocol\StdFileEditing\verb]

@=""

The next subkey in StdFileEditing is verb. Inside verb are one or more numbered subkeys; numbers begin with 0 and should be consecutive. Each verb that the OLE application uses in a menu will be included, as shown here:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\protocol\_StdFileEditing\verb\0]

@="&Edit"

This verb is the Edit menu selection. The text used in the menu is &Edit. The & indicates that the letter following it will be underscored and used as a hotkey value.

Finally, a version-independent ProgID is created. Even when the control is updated, this entry won't change:

HKEY_LOCAL_MACHINE \SOFTWARE \Classes \CLSID

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\VersionIndependentProgId

@="ComicChat.Room"

Like ProgID, this identifies the program, without any version references.

How Linkages Are Made between Applications

OK, now we'll look at a few of the mechanisms that Windows 2000 uses to manage OLE applications, CLSIDs, and the user interface.

First, let's confuse applications and documents. Considering them identical for now will ease some of the issues here. OLE is one complex puppy, so anything we can do to understand it is OK. Later in this chapter, I'll spend some time pointing out what the differences are between a document and an application.

OK, so the user's application wants to use OLE. There are a couple of ways that applications can use OLE:

  • Write the application from the get-go to use OLE controls. Some applications do this; however, many do not.

  • Write the application to allow the user to embed OLE objects into it. Many OLE applications do this.

Neither of these two scenarios is mutually exclusive. For example, an application could have both methods built into it. In either case, it is necessary to register the server of the OLE object that the client will be using.

When registered, the server's basic properties will be listed in the registry, in the HKEY_LOCAL_MACHINE \Software \Classes and HKEY_LOCAL_MACHINE \Software \Classes \_CLSID sections. This information in the registry provides the client with the minimum (got that, minimum) amount of information needed to interact with the OLE server.

However, the client application needs to know more about the server. Questions that must be answered include what the server does, expectations of the server, whether support for in-place editing exists, and what information or data is communicated between the server and the application.

An ActiveX control, for example, probably won't have any data that is stored in the client's document. Most ActiveX controls display information for the user. However, the displayed information varies greatly. Some ActiveX controls display contents that vary only in detail. A classic example of this type of ActiveX control is a real-time clock control—the control retrieves the time from the system and displays the time in a specified format. Another controls data changes in content, but not type. For example, the Comic Chat control always displays IRC chat sessions, though the sessions might vary widely. However, a Microsoft Paint server's data and type both would change from invocation to invocation. Who knows what the user might try to display in the Microsoft Paint control? The display could be anything from a company logo to a cheery holiday greeting.

Regardless, each server must communicate with the client application. The client always initiates communications between a server and a client; otherwise, how'd the server know a client needed it? This communication uses a technique called querying the interface. The server will respond with information about exactly what the server can do.

Everyone Uses OLE

Everyone uses OLE, we just don't realize it. The Windows 2000/NT and Windows 95/98 operating systems use OLE to perform a number of useful tasks. OLE is a built-in, not an added-on-later, part of Windows 2000.

Explorer, the Windows 2000 user interface, relies on OLE for many of its abilities. For example, look at your Desktop. Do you understand what is going on there? Probably not. Do you care? Maybe, and a bit of understanding can help later when you decide to customize it. One program, Explorer, is responsible for much of the functionality that you see on your Desktop. Explorer is the program that paints your Desktop background; puts up those icons (such as the pesky and difficult to remove Recycle Bin, My Briefcase, and My Computer); and manages aspects of the user interface, such as property sheets and context menus. This is all done with the very valuable assistance of OLE.

Let's give OLE a big hand—it does a lot for us.

Embedded Documents

Embedded documents will have references to each OLE object that they have. Unlike when OLE controls are used with an application (remember, we blurred this distinction in the previous section), OLE objects in a document can and do vary greatly. Each document is unique—one document may contain no OLE objects, while the next may contain many different objects.

Transportability is a critical issue. Say I create a chapter for my publisher and embed an OLE object into the document. Then I e-mail that document to my editor. When the editor opens the document and wants to have access to the object, the OLE server application will have to display the object on the computer. It is not necessary that the OLE server be in the same directory, or in any specific directory. OLE uses the registry to take care of locating the server and activating it as necessary. I might have the OLE server installed in a directory on my Q: drive, while my editor might have the same server located on the C: drive, and the executable filename may well be different in each installation, too. Regardless, as long as the ProgID value is identical, Windows 2000 will be able to locate the server and launch it.

Critical items in the registry are those entries shown in the previous sections of this chapter. If you find it necessary to move an OLE server's files from one location to another, it may be possible to edit the registry and change the file locations that are stored in entries, such as:

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \CLSID

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\DefaultIcon]

@=

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \CLSID

{241AF500-8FB6-11CF-ADC5-00AA00BADF6F}\LocalServer32]

@=

[HKEY_LOCAL_MACHINE \SOFTWARE \Classes \ComicChat.Room.1\protocol\_StdFileEditing\server]

@=

Note: Before making any change such as this, be sure your backups are up-to-date.

Warning: Don't even consider moving system OLE servers and objects. Leave anything supplied with Windows 2000 that is OLE related where it is. This is because it is possible that there are references to these objects in places other than the registry.

Fixing an OLE Disaster

Common OLE problems arise when a user inadvertently deletes the OLE server files, often in an ill-advised attempt to clean up hard disk space, while the OLE registry entries remain in the registry. There are several tricks to recover from this. First, attempt to reinstall a new copy of the OLE server in the original location. This will probably work in most cases. However, if you cannot reinstall—maybe you don't know where the source files are located—consider restoring the files from a backup.

As a last resort, try to remove the registry entries for the OLE server. This probably will result in your registry and system becoming unstable, but if it is unusable anyway, what do you have to lose? Check the sections listed here for entries about the OLE server:

  • HKEY_LOCAL_MACHINE \SOFTWARE \Classes \CLSID

  • HKEY_LOCAL_MACHINE \SOFTWARE \Classes

Doing this will require some detective work. You will have to search the registry using either RegEdit or by exporting the registry to a text file and using a text editor's search. While searching, note all locations listing the OLE server. There will be at least the two mentioned in the previous list, although some OLE components may have more entries.

Disaster typically raises its ugly head when there are multiple dependencies between a numbers of OLE objects. The fix here is to restore if possible.

Another disaster point is when a new application installs an OLE object that conflicts with an existing one. Typically, the two OLE objects would have different CLSIDs. However, it is possible that the CLSIDs are identical, although in theory this should not happen. Installing a second copy of an OLE object modifies the object's ProgID. The user will frequently see two OLE objects in the Insert Object dialog box with the same name. Often, only one of the objects will work correctly.

Hints and Kinks from the Experts

OK, there is a shortage of hints from the experts on OLE. I thought about making up some hints, but decided not to. I've included one hint from John Savill.

A Service or Driver Failed to Start and the Event Viewer Has Taken a Vacation

If you receive a message that a service or driver has failed to start, you are instructed to check the Event Viewer for details.

If Event Viewer has gone on vacation (all your All Users folders are gone) and/or no Network icon displays in the Control Panel, you may have a missing or corrupted Ole32.dll in the %systemroot%\System32 folder. Install a copy from the CD-ROM or from your latest service pack or hotfix, and then reboot your system.

(Courtesy of John Savill.)

About the Author

Peter D. Hipson is an author, consultant, and teacher. When not writing computer books, he can often be found teaching computer science at the local college, where he says he "ruins the lives of hundreds of unsuspecting college students every year." An avid Microsoft beta tester, he finds time to test and use virtually every product Microsoft produces.

Copyright © 2000 Sybex, Inc.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice. International rights = English only.

International rights = English only.


Click to order