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.