In an imperfect world, even perfection is flawed. Which you would think might make me feel a little better after rereading my last File Explorer Map Part post, but that turned out to be only true in part. What did make me feel better was compiling a list of further extensions and enhancements to the File Explorer Map Part.
Here's a fast bullet point summary of things that could be done to the File Explorer Map Part, with an eye to making it more flexible:
- Let the user adjust the Skip List - There's a hard coded set of file name specifications (*.exe, *.dll and the like) to ignore when generating file system topic content in the Refresh.mmbas. script. Would be nice to keep this as a default and let the user add or remove additional specifications.
- Let the user choose to always use the maximum possible folder depth - a persistent option to always expand the map part sub tree might be useful, but this expansion can be slow in the current implementation, particularly for deep file/folder hierarchies.
- Display File Explorer Map Part version number - Would be handy to know what version of the map part we're dealing with in a given Map document.
- Auto-expand the map part to some level less than or equal to maximum - Having a defined folder depth to limit tree expansion upon refresh might be useful.
- Solicit the user to provide a prefix string for either or both File and Folder topics - There's an unused feature in the stock implementation which could be used to prefix file and folder names in the topic text. Tying this to some file specification list might be handy, say "*.txt" files get a "Text File - " prefix.
- Speed up the file/folder traversal - The stock File Explorer map part uses the Scripting.FileSystemObject in a quasi-recursive manner. For more than 2 to 4 folder levels, or say more than 20 files or so, this implementation takes a while. A COM object built for the purpose could be much faster, and could perhaps support non-local-file-system protocols like WebDAV, FTP or even HTMLHelp.
- Provide an optional total file/folder count as Callout or Topic Text in the File Explorer Map Part - Since we have the information, it would be a user courtesy to annotate File Explorer Map Part topic text with a count of the number of files and folders beneath it in a Map document.
- Host a property grid in an actual property page dialog - If we're going to have all these user- settable values, we should put them in a Property Grid presentation, provide both default and per- instance settings, and support a "Restore Defaults" button to reset a given instance to the defaults.
- Remove the smiley robot face from message boxes and dialogs - OK, now I'm just whining. But I'd like to get rid of the smiling robot icon appearing in the upper left corner of WinWrap Basic message boxes and dialogs. It clashes with the rest of the MindManager UI look. "Mawkish Macro Manifestation" is a descriptive phrase for the appearance. (Don't wince, just look it up.)
Of course, these extensions would have to maintain compatibility with prior versions of File Explorer Map Parts. Or we should create a distinct map part using the MindManager GSMP technology and avoid the issue.
While generating this list might fall into a category labeled "Here Motion Gives the Illusion of Progress," it also let me fool around with the MindManager macro language with some sense of purpose. My primary source was the Language Help accessible from the MindManger Macro Editor (Tools->Macro->Macro Editor, then in the resulting window, Help->Language Help) Sparse help topics are provided for both the Integrated Development Environment (IDE) and the macro language itself.
Under the covers, the MindManager macro language is a Visual Basic compatible scripting engine known at the time of first release (1993? 1994?) as SAX Basic. This is the name appearing in the Help topics provided by the Macro Editor, with copyright cited for "1993-2001."
By the by, if you look at the set of executable modules loaded by the MindManager application program (say using the most excellent Process Explorer from SysInternals, there's a module called "SBE6_32.DLL." The version properties of this module give "WinWrap Basic" as a description, and "Polar Engineering and Consulting" as the vendor. A second, related component, SB6ENT.OCX, also appears in the MindManager process image. These modules carry copyright info with a 1993- 1999 date range.
A reasonable guess is that MindJet integrated the SAX Basic product in late 1999-2000, and has stuck with that version since. Sort of a bummer, since things have changed in the last seven years or so.
This Visual Basic compatible scripting engine product is now known as WinWrap Basic. New .Net features are planned for later this year, it appears the Polar Engineering developers are intent on maintaining compatibility as Microsoft platforms evolve. We can hope that MindJet will pick these up at some point, without major disruption to existing macros.
If I was looking for a procedural scripting engine to manipulate a COM-based application data model, WinWrap Basic would be a very attractive option when compared to integrating the legacy Visual Basic for Applications technology from Microsoft. Polar Engineering's WinWrap is particularly attractive if it continues to evolve to support .Net technology, freeing the application data model from the legacy Microsoft COM environment dominated by IDispatch.
However, MindJet has committed to support of both Windows and Apple editions of MindManager. It may be that the COM IDispatch level may be the most appropriate point of commonality between the two editions of the product. Common in terms of the concepts exposed, not the implementation.
The only product I'm familiar with that maintains scriptable object models for both Microsoft and Apple editions is Adobe Illustrator. While Illustrator is a very cool drawing package for commercial artists, I have no clue how much effort Adobe expends on maintaining parity between the Microsoft and Apple scripting interfaces. With respect to Illustrator, it appears that Adobe obtained a certain level of common functionality, and let it go at that, choosing instead to focus on workgroup and workflow features involving the rest of the Adobe Creative Studio product portfolio.
Lacking the stable of related products enjoyed by Adobe, and operating in a distinct market segment without the deep history of graphic art production, MindJet probably doesn't have the option of "being just good enough" with respect to a procedural scripting engine. However, large opportunities exist by blending procedural scripting with declarative XML technology. Seems to me that an XProc implementation hosted in MindManager could be a powerful way to manipulate the content of one or more Map documents, hosted locally or behind some yet-to-be-designed web service.
But then again, I'm a MindJet customer. Without any knowledge of current product plans, I can wish for whatever I can dream up. Ah, such luxury.