# Component Categories Manager Implementation

As the number of available components grows, it becomes increasingly difficult to manage these components. Many components offer similar functionality, both in terms of the interfaces they expose as well as the tasks they perform.

In many situations, it is necessary to enumerate the components that can be used in a certain context. Examples of this are the Insert Object dialog box used in OLE Compound Documents and the Insert Control dialog box used in OLE Controls. These dialog boxes list all components that fulfill (or claim to fulfill) the interface contracts for compound documents or controls. These existing categories (OLE Document, OLE Control) do not imply an exact interface signature. OLE Documents have to expose a certain set of core interfaces (for example, IOleObject or IPersistStorage), but can also expose additional interfaces such as IOleLink.

In the past, components have been tagged by adding a human-readable name (“Insertable”, “Control”, and so on) as a sub-key to the HKEY_CLASSES_ROOT\CLSID\{...} key corresponding to the component. This works well for a central definition of categories, but runs the danger of name collisions when many independent parties define new categories. As in other areas of COM, the solution to providing an extensible name space lies in the use of globally unique identifiers (GUIDs). Instead of using a human-readable name, a unique number (CATID) is assigned to each category.

Another limitation with the existing categorization is that it is limited to expressing the capabilities of the component itself. Many components require certain capabilities from the containers. When such a component is inserted into a container, the insertion can fail or behave unexpectedly, even though the component fulfills the contracts implied by one of its categories. To enumerate the components that can be used successfully in certain situations, both the capabilities of the component and the container must be considered.

Because of these considerations, the following changes were made to the existing categorization:

- Categories are indicated by using CATIDs that are globally unique identifiers.

- Under the Components sub-key of the HKEY_CLASSES_ROOT\CLSID Registry key, two separate sub-keys, “Implemented Categories” and “Required Categories”, were developed. These sub-keys contain the lists of CATIDs that are provided by the component or that the container of the component must provide.

To ease managing the component categories, categories are listed in a central place in the Registry: HKEY_CLASSES_ROOT\Component Categories. This key lists the installed categories with both their CATID and localized, human-readable names.