C++ Code Only

The following considerations apply only to C/C++ developers:

  • Namespace extensions have a special purpose. Only a single instance of a namespace extension is created for a single instance of the snap-in that it is extending, regardless of the number of nodes that it extends. Thus, a namespace extension must maintain several "trees" of nodes, one per node extended. Ensure that this logic is coded into the snap-in.
  • Check data objects and cookies that use the macros IS_SPECIAL_DATAOBJECT and IS_SPECIAL_COOKIE to ensure that the special data objects and special cookies are handled appropriately. Every snap-in should handle a NULL cookie because MMC uses this value to refer to the static node belonging to a stand-alone snap-in. Every snap-in should handle a NULL data object because some notifications such as MMCN_DESELECT_ALL and MMCN_PROPERTY_CHANGE send a NULL data object by default.
  • For history and view persistence to work well, ensure the snap-in handles MMCN_RESTORE_VIEW appropriately.
  • Verify that IComponentData::Notify, IComponent::Notify, and IExtendControlbar::ControlBarNotify return S_FALSE to notifications they do not handle.
  • For data objects, support the new CCF_NODEID2 clipboard format, not the old CCF_NODEID format.
  • If you use Wizard97 wizards, ensure that you implement IExtendPropertySheet2::GetWatermarks and that it returns S_OK.
  • If you are using Microsoft Foundation Classes (MFC), you should call AFX_MANAGE_STATE. If you do not make this call, the module and thread state will be wrong and it can be difficult to debug the problem.
  • Snap-ins can return S_OK from IComponent::CompareObjects only if the two objects that expose an IDataObject interface for comparison refer to the same object.
  • The notification handler for a snap-in should return S_FALSE by default. The S_FALSE value triggers the default operation for the notification. Failure to follow this strategy could limit future functionality.