OLE Registry Entries

To become functional, OLE servers and containers must add information to the system registry. Most of that information is stored in keys and named values under the HKEY_LOCAL_MACHINE\SOFTWARE\Classes and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLE keys. This section discusses these registry keys and information Orequired to support OLE functionality. For general information on the registry, the structure of registry entries, and registry functions, search for Registry topics in the Microsoft Win32 Programmer’s Reference.

Note that HKEY_CLASSES_ROOT is equivalent to HKEY_LOCAL MACHINE\SOFTWARE\Classes and that these keys can be used interchangeably. HKEY_CLASSES_ROOT also provides compatibility with Windows 3.1 and Windows 95.

Installation and Setup

Your installation/setup program must add information to the registry, and its associated subkeys, if it is to perform any of the three following types of installations:

Installing an OLE server application.

Installing an OLE container/server application.

Installing a container application that allows linking to its embedded objects.

In all three cases, you must register OLE 2 library (DLL) information as well as application-specific information.

For information on registering COM servers, see Registering COM Servers..

OLE Registry Functions

For information about OLE registry functions, refer to the following API functions:

Registering OLE 2 Libraries

The OLE 2 libraries require that many internal interfaces be registered. If your installation program installs the OLE 2 libraries on a machine that does not already have them, it should register OLE 2-specific information during installation.

If your installation program does not install OLE 2 libraries when it finds more recent libraries on the user’s drive, it should not register the OLE 2 interface information.

Note When checking the version stamp (using VER.DLL) on existing OLE 2 libraries to determine whether or not to replace them on the user’s hard drive, check on a per file basis.

Checking Registration During Run Time

An application should check its registration at application load time, noting the following issues:

If the CLSID(s) that the application services is not present in the registry, the application should register as it does during the original setup.
If the application’s CLSID is present, but has no OLE 2-related information in it, the application should register as it does during the original setup.
If the path containing server entries ( LocalServer and LocalServer32, InprocServer and InprocServer32, and DefaultIcon) does not point to the location in which the application is currently installed, the application should rewrite the path entries to point to its current location.

Specifying Unknown User Types

It is possible to facilitate product localization by adding a key to the registry. This key allows functions to return a specified string instead of a default value or “Unknown."

The OLE 2 default handler’s implementation of IOleObject::GetUserType first examines the registry by calling OleRegGetUserType. If the object’s class is not found in the registry, the User Type from the object’s IStorage instance is returned. If the class is not found in the object’s IStorage instance, the string “Unknown” is returned.

By inserting the

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OLE2
\UnknownUserType = <usertype>

key in the registry, the IOleObject::GetUserType method returns the value of the string specified by <usertype>. This string can be localized for a different language user-type name, instead of using the “Unknown” string, for the User Type.

Conventions Used in Examples

In the registry examples in this appendix, boldface indicates a literal standard key or subkey, <italics> indicates an application-supplied string or value, and <boldface-italics> indicates an application-supplied key or subkey. In the first example, “OLE1ClassName,” “OLE1UserTypeName,” and “CLSID” are all supplied by the application.