The rattled cough of a Hyper-Empathetic PM

The MM VS2005 AddIn wizard created a set of Registry settings for my project, and the friendly folks at Mindjet’s Dev Support team helped me fix a problem with my project (and in the process had to remove most of those Registry settings). Well, now we’re taking it back [anyone else remember Bono’s intro to Helter Skelter?].

It took me a bit of time to track down the hidden place where Visual Studio “hides” the Registry settings for a Setup project: right-click the Setup Project (“AddInSetup_en” in this case), choose View, Registry. There’s a stub for each hive, but not all of them contain actual Registry Keys or Values.

For my project, the only Key with any entries was HKLM\Software\Mindjet\MindManager\7\AddIns, with the Values (though different settings) that I’d noted earlier. The ProgID that it’s setting is ParanoidMike.ToDoListBuilder.AddIn which isn’t really representative of what I’m intending to release – ToDoListBuilder is just one portion of the functionality I want to provide (i.e. I’ve also spec’d out a ToDoListManager class that’ll be a peer to ToDoListBuilder).

Also, if I’m going to define a namespace rooted in ParanoidMike, I figure I should use the application name as the next-level-down, and then describe the actual code/app/add-in as the third-level-down. That gives me the namespace ParanoidMike.MindManager.ToDoListAddIn, so I’ve replaced the existing ProgID with this as the new ProgID (and .NET namespace for my source code). I deleted the old Registry entries that reference this ProgID, added the new ProgID and its entries, and also added the HKCR settings that were still missing when I published this article.

That results in the following Registry entries populated in the AddInSetup_en project:

Complete Set of Registry Entries for MM7 Add-in

HKLM\Software\Mindjet\MindManager\7\AddIns

HKCR\ParanoidMike.MindManager.ToDoListAddIn

HKCR\ParanoidMike.MindManager.ToDoListAddIn\CLSID

Note: this little tip (HowTo: Create a Default Registry Value in Registry Editor) saved me a lot of trouble futzing around with these infrequently-created values.

Note: if you’ve used the MM7 AddIn template for Visual Studio, the CLSID above can be found in the Connect.cs file just under the ///

comment, like so:

GuidAttribute("33B60353-E8F3-4F38-98B6-41C7E5C6D32B")

Open Issue: ProgID versioning

There’s conflicting evidence on whether it’s best to create the ProgID using the “.1” suffix notation, so that the ProgID can be rev’d, or whether it’s just as good to leave it without the “.1” suffix and replace it upon every install (upgrade?). For the moment, until I stumble across anything better, I’m just going to leave it without.

Open Issue: ProgId in AddIn’s source code

After cleaning out the old entries from my computer’s Registry and testing this new set of code, I noticed that there was still the old ProgId referenced in the Connect.cs code:

    /// 

    ///   The object for implementing an Add-in.
    /// 
    ///    
    [
     CLSCompliant(false),
     ComVisible(true),
     GuidAttribute("33B60353-E8F3-4F38-98B6-41C7E5C6D32B"), ProgId("ParanoidMike.ToDoListBuilder.AddIn")
   ]

Since the add-in loaded and executed successfully, I’m now left to wonder what effect this ProgId entry is really supposed to have. Clearly it doesn’t affect the operations of debugging the code (i.e. hitting F5 from within Visual Studio 2008 and waiting for MindManager to launch), but I can’t imagine it’s just there for decoration either. It’s possible that, because I haven’t rebooted since I cleaned out the Registry and updated the AddInSetup_en project settings, there’s still enough of this information cached to allow the Add-in (with the same CLSID) to still work.

I’m taking no chances of a vaguely-specified error down the line, so I’ve updated this ProgId entry to the current value, but if anyone knows how these entries are related, I’d sure love to hear it.

Notes to Self: Object Model stuff I Might Use in my Add-in

• Application.ActiveDocument: the currently-displayed Map
• Application.Visible: enables/disables the MM UI
• DocumentObject.Guid, DocumentObject.ResetDirty: this seems like a generic object type within the MM object model — might be useful for manipulating a whole collection of different objects at once
• Document.Attributes: collection of document’s custom attributes
• Document.CentralTopic
• Document.Guid
• Document.IsModified
• Document.Properties
• Document.AssignMapMarkers(): assigns a map markers template to the document
• Document.GetAttributes()
• Document.Range(): returns a new Range collection of all the specified objects (topics, boundaries, relationships) in the document
• Topic.AllSubTopics: subtopics connected to the topic
• Topic.Attributes
• Topic.Document: the document in which the Topic is found
• Topic.Guid
• Topic.Icons, Topic.UserIcons
• Topic.IsFirstSibling: TRUE if the topic is the first in a set of siblings
• Topic.IsMainTopic: TRUE if the topic is a child of the Central topic
• Topic.IsSubTopic: TRUE if the topic is a child of another topic
• Topic.Level
• Topic.NextSibling
• Topic.ParentRelationship
• Topic.ParentTopic
• Topic.SubTopics, Topic.UnfilteredSubTopics
• Topic.Synchronization: ????
• Topic.Task
• Topic.Text
• Topic.TopicLabel
• Topic.TopicPrefix: sets the prefix for the topic — something to do with “numbering”
• Topic.Type
• Topic.AddControlStripType()
• Topic.AddSubTopic()
• Topic.CreateHyperlinkToTopicByGuid(): Cool! This could be used to hyperlink topics in ToDoList back to their original Topics. Might be useful to sync properties, attributes automatically.
• Topic.GetAttributes()
• Topic.NewTopicFinder(): helpful for traversing sub-topics from the current topic.
• Topic.ResetDirty(): resets dirty bit of this and all subsequent objects. [Could be used to determine if a Topic has been changed since last “sync”.]
• Topics.Add()
• Topics.AddWithGuid(): creates new Topic with a given Guid
• CustomProperty.Value
• CustomAttributes.GetAttributeValue(), CustomAttributes.SetAttributeValue()
• Task.IsDone
• Task.IsValid
• Task.Priority
• Task.Topic: the parent Topic for this object
• TextLabels.AddTextLabel()
• Icons.AddStockIcon(), Icons.AddCustomIcon()
• Icon.Delete()
• Utilities.Execute

Notes to Self: Questions to Research

1. What’s the difference between a CustomProperty and a CustomAttribute?
   • Attributes are persistent
   • Nick Duffill has more info here
2. Is a TextLabel the same thing as a Text Marker?
3. What’s the difference between a CategoryMarker, a CustomIconMarker and a CustomIcon?
4. What Events are available to which to respond (such as Topic.Moved)?
• Nick Duffill alludes to “topic-delete” and “topic-add” here
5. Is there a way to find the current position among siblings for a Topic? Could there be a Property that indicates the Topic’s position?
• There is the Topics.Item property…
6. Can you get a handle to a Topic when you know its Guid? Do you need to be attached to its Document, or can you search all open Documents (e.g. searching through the AllDocuments or Documents collections)?
7. Is there some way (e.g. derive a class from the Topic class) that would allow me to define a Property whose Value was equal to its 1-index position among its siblings?
8. Does the Dirty flag get toggled automatically as soon as any change is made to the object? Or is this a flag that must be explicitly set?
9. Does the Dirty flag inherit up the tree — i.e. if any Object in a Document has the Dirty flag set, does that implicitly “set” the Dirty flag on the Document as well?
10. Can you reset the Dirty flag on a Document, and would that reset the Dirty flag on every Object in the Document all at once?
11. Could the InsertCustomProperties event be used to automatically propagate a Property to another attribute on the Topic object (e.g. taking the Index of a Topic next to its ToDoList siblings and convert that to a custom ToDoListPriority property, or to use the Priority icon’s value as a ToDoListPriority value)?
12. Is the SetCustomPropertyValue event the one that’ll let me trigger when the user changes the Topic’s ToDoListPriority value (either automatically, by moving the Topic to a different position among its List siblings, or manually, by typing the value in or selecting it from a pre-populated list) to propagate that value back to the source Topic?
    • If so, could I reset the Dirty flag on the Topic in the ToDoList, but leave open the possibility that the ToDoList overall is still “Dirty” and prompt the user to save unsaved changes?

Notes to Self: MM-specific Objects to Manipulate

There’s all these new Object types defined in the MM object model:

• BusinessTypeRegistry/Business Topics (see Nick Duffill’s expert explanation of these Object classes here)
• External Topics
• Map Parts
• MapShortcutCollections
• Baselines
• DocumentBars
• Filter
• Control Strips

Notes to Self: Code Tidbits

“use the Document.Range() method to iterate over all Objects” (Create and Use Custom Attributes)

Add Topics

Iterate over Topics (includes sample code for using the TopicFinder, an iterator)

Work with the Object ID (includes reference to FindByGuid() method that finds DocumentObjects by GUID in any Range, such as Document.Range)

Get an Object’s Type (which refers to an enumeration of DocumentObject that includes mmDocumentObjectTypeTopic)

Successful running of the add-in!  Once I added the required Registry settings, the add-in finally made itself known (through the MessageBox’es).  I learned that the HKCR settings are also necessary for other calls to succeed, but the essential behaviour of being recognized and loaded by MindManager was entirely dependent on having those Registry settings populated in the \Addins key.

At first I just used a .REG file to populate the Registry settings, following the model of the MM7 Sample Addin.  I had to do this as a side-effect of the work the helpful folks on the Mindjet “Dev Support” team did to rip out a bunch of “custom actions” stuff from my MM7 add-in solution, and this appears to have included all the Registry settings as well.  [Note: the Mindjet dev support folks are really helpful, and I’m not blaming them for this — the MM7 VS project template was (a) developed under Visual Studio 2005 not 2008 (which I’m using), and (b) was last updated last summer (and is no currently under active development I’d guess because the person who originally created it has since left the company — at least, that’s the usual way these things occur).

However, it’s not quite perfectly operating yet — just before the OnStartupComplete dialog box comes up, the following error is thrown by MM7:

According to this thread, this means that Addin ID must match the first parameter to applicationObject.Commands.Add().  In my code that parameter is “ParanoidMike.ToDoListBuilder.AddIn”, and my first guess is that the key under HKLM\Software\Mindjet\MindManager\7\AddIns needs to have the same name (which it currently doesn’t).  Upon changing it to match, I finally saw the Add-Ins Ribbon tab that I hadn’t been able to expose until now.

On to a little code…

First stage: Ribbon Button That Counts Tasks in Current Map

I wanted to use as much of the code from the MindManager7 Sample Add-in as possible… however somehow I ended up not using much or any of that.  This was my original plan:

1. Create variable for MM application
   • Sample\MmxUtility\Helper.cs: MmxUtility.Helper.GetMmxMap()
2. Beg/borrow/steal ribbon button code from existing add-in
   • Sample\MmxUtility\RibbonTabBase.cs (base class for creating a new Ribbon tab)
   • Sample\MmxUtility\ControlStripBase.cs
3. Attach function to Ribbon button
4. Create variable for Current Map
   • Application.ActiveDocument
5. Find the Base Topic and enumerate
   • Sample\MmxUtility\Helper.cs: Helper.BaseTopicFinder()
6. Create variable for Count
7. Create For Each loop of Task objects, and count ’em
   • Sample\MmxUtility\Helper.cs (Topic attributes)

Instead, though, I ended up trying to separate out the UI from the data manipulation code, and leveraging the code I’d written from the MindManager DevZone article “How to Create a MindManager 7 Add-in Using C#“. 

This is what resulted:

        private void mmCommand_Click()
        {
            // Process the MindManager command and say hello
            MessageBox.Show("Hello world! (C#)", addInDisplayName);

            // Get the current Map
            Mindjet.MindManager.Interop.Document currentMap;
            currentMap = applicationObject.ActiveDocument;

            // Count the current Map's Tasks and display for the user:
            int count;
            ToDoListBuilder taskCounter = new ToDoListBuilder();
            count = taskCounter.countTasks(currentMap);
            MessageBox.Show("There are " + count.ToString() + " Tasks in this Map");
        }

    class ToDoListBuilder
    {
        public int countTasks(MMInterop.Document mindMap)
        {
            int tasksCount; // count of the number of Topics that are Tasks
            MMInterop.Range range; // just a collection of whatever we can find in the Document 🙂
            range = mindMap.Range(MMInterop.MmRange.mmRangeAllTopics, true);
            tasksCount = 0; // initialize to avoid error CS1065
            foreach (MMInterop.Topic topic in range)
            {
                if (topic.Task.Complete >= 0)  // this is intended to test whether the "topic" has Task attributes attached to it, and is how ResultsManager characterizes a Task
                {
                    tasksCount++; // increment this counter variable
                }
            }
            return tasksCount;
        }
    } 

The key magic in this code was the test for whether a Topic is a Task or not:

if (topic.Task.Complete >= 0) 

I’d spotted this approach in a macro that was published on ActivityOwner, but it seemed more complicated and indirect than should be necessary.  I wondered whether something like topic.Task.IsValid() would identify whether a topic had “valid” Task characteristics.  I looked into what documentation for this method was available, but the available info is pretty sparse.  If not for the generous help from the MindManager development community like Nick Duffill, I would’ve been forced to work through this by trial & error.