Interfaces and Thread-safety
Because they are not thread-safe, and because Proppage and dialogs run on
their own threads, it is recommended that you not use Interfaces inside of these
items, but rather, send a custom message to the message pump for CComponent
and/or CComponentData, so that the processing is serialized (add comment to
template to this effect). * Create hidden window to get all Interface work into
UI thread. Serializes work.
Result Views
When you add/delete multiple result views, here are some issues you need to
be aware of: * There is no way in MMC to track how many result views there are
or which one has the focus. * Each result view can have it's own result pane. *
UpdateAllViews()/ComponentNotify() - Each instance of IComponent should track
it's current scope node.
Hot Spots
The following two methods are MMC hot-spots:
- GetDisplayInfo()
- QueryDataObject()
Performance and Complexity Notes
- Use WCHAR not TCHAR definitions. This is because MMCCrack does extra
processing for TCHARs.
- Notify(): If you choose to pass data objects, make sure they are simple
and straightforward. Avoid complex or bizarre structures. Make sure each
object has a unique identifier.
MMC/MFC Tricks
- Under Windows XP, there may be a bug where grayed out controls don't gray
out.
- The main MMC handle is actually a CMainFrame handle, and can be cast to
this. This is not a documented situation, but is the reality and is unlikely
to change. You can use this to get a list of controls.
- Allocate all objects on the heap, not the stack.
IExtendTaskPad
- Not supported by Microsoft anymore. Not recommended that you use it. In
it's place, for MMC 2.0 use extended view, for MMC 1.2, use URL view.
Working With OCXs in MMC
- An OCX always runs on it's own thread.
- Always cache the OCX.
- Never use the CREATE_NEW flag.
- OCX must manage state internally for each Node and Parent.
- Let OCX know that it's scope node was deleted.
Extending Existing MMC Snapins
- Be careful.
- Can have pitfalls.
- Parent is blind to extension nodes.