[This is preliminary documentation and subject to change.]
Snap-in components and the objects they manage are represented in the scope pane as nodes on a tree control. These nodes can be divided into three types:
Built-in nodes include shortcuts, HTML pages, ActiveX™ controls (OCXs), and several other categories. They are implemented by MMC and do not interact directly with your snap-in OLE server. The other two types of nodes, static and enumerated, each offers a viewing mechanism: details view, HTML control, and OCX.
A node's most important property is its node type (known by your system as the nodetype). This is a GUID (a COM acronym that stands for "globally unique identifier") that describes the node's overall type such as whether it's a user, a machine, a domain entry in a DNS database, or something else. A node type is defined by the individual snap-in rather than by MMC and even though it is a GUID, this is so only because it is a dependable way to avoid name collisions. GUIDs in this context have no COM significance, although you generate them using uuidgen.exe just as you would other GUIDs. This procedure is documented in the OLE Programmers Reference included in the Platform SDK CD.
Every node type implies one or more clipboard formats that a data object for any node of that node type must support. For example, the node type for a user might imply that the object supports clipboard formats that provide the domain where the user is located, plus the distinguished name of the user. With a few exceptions these clipboard formats, and the format of the data they return, are defined by the snap-in, not by MMC. For example, a snap-in could show the NodeType in both GUID and string formats. Entering these clipboard formats in the system registry to make them available for use could then be done by using the Win32 RegisterClipboardFormat function, which is documented in the Platform SDK.
Each data object must support four specific clipboard formats:
CCF_NODETYPE
CCF_SZNODETYPE
CCF_DISPLAY_NAME
CCF_SNAPIN_CLASSID
The first two are the node type's GUID in CLSID (class identifier) and string form. CCF_DISPLAY_NAME is used by MMC's Snap-In Manager to provide the snap-in an opportunity to change the default name of the snap-in. Finally, CCF_SNAPIN_CLASSID is the snap-in coclass identifier. For more information about CLSIDs and related topics, see the Microsoft Platform SDK.
In all cases, MMC uses IDataObject::GetDataHere and specifies the medium and format. For example, MMC (through the node manager) determines the node type by calling IDataObject::GetDataHere on the data object for a specified node, using clipboard format CCF_NODETYPE. This particular format must be supported but this does not imply that MMC treats nodes differently according to node type; instead, the node type provides a way to determine which other snap-ins extend that node. For example, when a snap-in registers itself as extending the property sheets of objects generated by other snap-ins, it actually extends the property sheets for nodes of one or more specific node types. The GetDataHere method is provided as part of COM and is documented in the Platform SDK.
A static node is a node in the MMC namespace that is present as long as the snap-in providing it is loaded. Snap-ins must implement IComponentData to have static nodes in the tree. The first time a static node is accessed in an MDI child, MMC calls CoCreateInstance to create an instance of the snap-in COM server that owns this static node in this MDI child. Each static node in each MDI child has a different instance of the COM server, even when the same snap-in owns more than one static node, or when the same node appears in more than one view.
Standalone snap-ins use static nodes to store their setup configuration and relative placement in the console. This node is inserted when the snap-in is added to the console on behalf of the snap-in. It has a cookie value equal to NULL. The snap-in needs to be prepared to get notifications on a NULL cookie just like any other node.
Every static node in each MDI child can have its own subtree of enumerated nodes. These enumerated nodes are not persisted by MMC to the .MSC file; rather, the snap-in rebuilds them in each view as needed. The children of enumerated nodes are always other enumerated nodes, never static or built-in nodes.
When the user selects or expands the static node in the scope pane, the snap-in's implementation of IComponentData is notified and gets the opportunity to add enumerated nodes as children of that static node. Similarly, the same IComponentData is notified when one of those enumerated children is selected or expanded. The same IComponentData serves the static node and all of its enumerated children belonging to the snap-in that owns the static node.
If there is more than one MDI child viewing a static node, the node will appear the same in each MDI child.