Control-Specific Registry Keys

To round out our discussion of the OLE Controls architecture, we'll cover two registry keys that a control should include. The first is simply named Control, which a control can include under its CLSID alongside entries such as Insertable and InprocServer32. This is the only means by which to mark a registered object as an OLE control. Containers can use this key to populate an Insert Control dialog box.8 Controls that are useful only to containers that know more about them might not include Control in the registry, requiring a container to know the control's CLSID ahead of time.

The second key is named ToolboxBitmap32. Its value is a path to a DLL or an EXE and a resource identifier such as is used for the DefaultIcon entry we saw for OLE Documents. This key allows a control container to extract a 16*15 button face image for a registered control appropriate to display in a toolbar or tool palette (such as that which Visual Basic uses). Usually the module registered for ToolboxBitmap32 will be the same as the control's server module itself.

A control might or might not include the Insertable key under its CLSID. The key indicates that the control can be inserted into an OLE Documents container as a regular in-place–capable embedded object. This means that the control supports storage-based persistence and doesn't rely on a container to provide event sinks, extended controls, ambient properties, handling of control specific MiscStatus flags, or IOleControlSite. Including this key with a control means that you've made a conscious effort to test the control with noncontrol containers, that the control is prepared to work with a container, and that the control still provides value in such scenarios.

When a control does include Insertable, it should add Properties to its list of verbs. When this verb or OLEIVERB_PRIMARY shows up in IOleObject::DoVerb, the control should display its own property pages. This allows users of noncontrol containers to still manipulate the control and its state without requiring any interaction from the container.

An OLE control should generally be self-registering so that the control's DLL (or EXE) is all that one needs to copy to another machine in order to have a fully functional control (within the bounds of licensing, of course). Accordingly, a control container should provide some sort of user interface to invoke a control's self-registration facilities. This can amount to little more than a File Open sort of dialog or a more elaborate control browser—whatever is appropriate for the container.