Database entries that are one level below the HKEY_CLASSES_ROOT root-level entry are defined as classes of documents. The exception to this definition is the .ext class.
Database entries that are subordinate to the class-definition entries describe the properties of a class. The database can describe two kinds of document properties for each class of document: shell properties and protocol properties.
The .ext key name defines all files with that extension as members of a specified class. The registering application specifies the document class for an extension in the text string associated with the .ext key name.
Unlike other second-level key names, the .ext key name is not a class definition. Instead, it helps associate a class with a specific filename extension. For example, a word processor application can define a .DOC filename extension with the text string wpdoc. Then, when the word processor uses wpdoc as the class name for its documents, the .DOC extension is associated with that class.
The class name is the same name used by an OLE server application when it registers itself. For example, if a voice-annotation application named TALK.EXE registered as an OLE server, the information would look like this:
HKEY_CLASSES_ROOT\.tlk = Talk
HKEY_CLASSES_ROOT\Talk = Talk Voice AnnotationFilename extensions are recorded both in the database and in the [extensions] section of WIN.INI when the user records a filename association in the Associate dialog box. The Associate dialog box is displayed when the user chooses the Associate command from the File menu in File Manager. (Although File Manager automatically records the information in both places, SHELL.DLL does not. Applications that register filename extensions in the registration database should also record the information in WIN.INI, to provide compatibility with applications written before Windows 3.1.)
File Manager uses the filename associations recorded in WIN.INI if the information is not found in the registration database. If information is duplicated in the database and WIN.INI, File Manager uses the information in the database.
Shell properties describe how a document of a given class interacts with Windows shell applications. There are two key names for shell properties: open and print. The open properties describe how the class responds to a request from a Windows shell application to open a document. The print properties describe how the class responds to a request from Print Manager to print a document.
Both the open and print key names must have the command subkey. The value assigned to command specifies the command line used to run the application. If appropriate, this value can include command-line options.
If an application supports DDE, it can also define the ddeexec subkey for either or both of the open and print key names. The text string given with the ddeexec key name is treated as a DDE command. Defining ddeexec is particularly useful if an application already supports DDE open and print commands. Using DDE messages can add flexibility, particularly for applications that support the multiple document interface (MDI), because a DDE message string can include more than one command.
The ddeexec key has three predefined subkeys: application, topic, and ifexec.
The text string given with the application key name specifies the application name to use in establishing the DDE conversation. If the registering application does not specify an application key, the shell uses the application name specified in the command key.
The text string given with the topic key name specifies the topic name of the DDE conversation. If the application does not register a topic key, the shell uses the System topic as the default topic name.
The text string given with the ifexec key name defines the DDE command to use when initiation of the DDE conversation fails (for example, if the application is not running). When the initiation fails, the command specified by the command key is carried out and then the string specified with the ifexec key is sent. (If an application does not specify a value for the ifexec key, the command specified by the command key is executed when initiation fails and the string specified with the ddeexec key is sent again.)
An application should open a file in a new instance of the associated application, even if the application supports MDI. If the user has already opened the file, applications typically give the focus to the window with the file instead of obtaining a new copy of the file.
If an MDI application does not use memory efficiently when multiple instances
of the application are running, the application can open the file in the existing
instance, as a new MDI window.
After opening the file as described in the preceding section, the application should carry out the print command. Whenever possible, applications should display the Print dialog box to give the user the opportunity to customize the print job. If this is not possible, the file should be printed immediately. Once the file is printed or the user chooses to cancel the print job, the application should close. (If the file was opened as a new MDI window, the application typically closes the window, rather than the entire application, when the print job has finished.)
A protocol is a convention for manipulating a document or some other collection of data. Database entries that are subordinate to the protocol key name describe the properties of a protocol. Although a class can support any number of protocols, currently only one is defined. This protocol, StdFileEditing, is used by documents that support OLE.
The StdFileEditing protocol has three subkeys: server, handler, and verb.
The text string given with the server key name is a command line that an OLE client application uses to start the server application for a linked or embedded object.
The text string given with the handler key name is the name of a dynamic-link library that acts as an object handler for OLE objects. For more information about object handlers, see Chapter 6, “Object Linking and Embedding Libraries.”
The verb key name has subkeys that identify the kind of action a server should take when it opens an object. These subkeys are consecutive numbers, beginning with zero. The 0 subkey corresponds to the primary verb for the objects supported
by the server. For example, 0 often means Edit and 1 often means Play. For
more information about verbs, see Chapter 6, “Object Linking and Embedding
Libraries.”
For example, if an application named NewApp could not use REGEDIT.EXE to set up its protocol properties, it could set them up by using the following example:
HKEY hkProtocol;
if (RegCreateKey(HKEY_CLASSES_ROOT, /* root */
"NewAppDocument\\protocol\\StdFileEditing", /* protocol string */
&hkProtocol) != ERROR_SUCCESS) /* protocol key handle */
return FALSE;
RegSetValue(hkProtocol, /* handle to protocol key */
"server", /* name of subkey */
REG_SZ, /* required */
"newapp.exe", /* command to activate server */
10); /* text string size */
RegSetValue(hkProtocol, /* handle to protocol key */
"handler", /* name of subkey */
REG_SZ, /* required */
"nwappobj.dll", /* name of object handler */
12); /* text string size */
RegSetValue(hkProtocol, /* handle to protocol key */
"verb\\0", /* name of subkey */
REG_SZ, /* required */
"Edit", /* server should edit object */
4); /* text string size */
RegCloseKey(hkProtocol); /* close protocol key and subkeys */When an application creates a server protocol property and saves this key in REG.DAT, SHELL.DLL also puts this information into the WIN.INI initializa-tion file. Some applications that use linked and embedded objects were devel-oped before the implementation of the registration database. The information in WIN.INI allows such an application to find the command line that starts the server for an object. Server registration entries in WIN.INI are also written to the registration database whenever the user starts Windows.
The server registration entries in WIN.INI are in a section headed [embedding]. If an [embedding] section does not already exist when a registering application calls the RegCloseKey function for a key, SHELL.DLL creates it. When an application calls RegCloseKey, every class-definition key in REG.DAT that is not already in the [embedding] section is added to WIN.INI, not simply the key for which RegCloseKey was called.
The server information in WIN.INI is recorded in the following form:
[embedding] ClassName=comment,textual class name,path/arguments,Picture
The keyword Picture indicates that the server can produce metafiles for use when rendering objects. Because commas are used as field separators, none of the fields can contain a comma.
A server can register only the name and arguments for its executable file, rather than the entire path, if the application is always installed in a directory that is mentioned in the PATH environment variable. Usually, registering the path and filename is less ambiguous than registering only the filename.
When the database is opened, the shell library reads the [embedding] section
of WIN.INI and updates the registration database with any new information it
contains. If the [embedding] section contains information that conflicts with REG.DAT, the information in REG.DAT is overwritten. When the database is closed, the shell library writes the information in REG.DAT back into the [embedding] section of WIN.INI. This ensures that applications that depend on WIN.INI for information about linked and embedded objects retrieve current information and that new OLE applications can simply read from and write to REG.DAT.