After a bit of work this weekend, I am happy to announce that v1.1 of the DX_SourceOutliner Visual Studio Add-in is ready for download. You can get the latest binary release from the Google Code site here.
Originally supposed to be just a bug-fix (which would have left it at v1.0), while working on it this weekend I decided to take the time to introduce a few additional features as well, so the version went from 1.0 with a bug-fix to 1.1 with the new features.
Due to the way in which the DXCore semantic code model is constructed, there are actually two different LanguageElements used to represent field declarations in a class (Variable) and field declarations in class with an initialized value (InitializedVariable). Because DX_SourceOutliner v1.0 had no code to handle elements of type InitializedVariable, any field declaration in a class that also included an initial value (e.g., bool _myFlag = true;) wouldn’t show up in the treeview. This bug is now resolved in v1.1.
The New Features
The new features for v1.1 are (relatively) minor, but taken as a whole should improve the tool’s usability.
As shown in the following screenshot, there is now an ‘All’ toggle button for each of the three node-category filter button groups, Members, Types, and Access as described in this issue. Clicking the ‘All’ toggle button for each of the categories will turn all toggles in that category ON or OFF accordingly. This should permit quicker management of the button toggles and reduce the need for as much mouse clicking to set different combinations of filters on and off.
Next, the double-click behavior has now been changed to not only move the editor window to the correct element declaration, but also to select the declaration and ensure the cursor (editor caret) is positioned at the actual identifier as described in this issue. Previously, the double-click behavior was to select the entire LINE in the code editor. While this resulted in better visibility for where the heck the cursor had been placed, since the editor-line-selection resulted in the cursor being placed at the column-zero of the editor (the left-most column of the line), users couldn’t immediately invoke any refactoring of the element that was navigated to without first moving the cursor into the actual declaration text of the element. Now, after double-click the cursor remains logically ‘within’ the element receiving focus, so the editor is ready for you to immediately invoke a refactoring (using CodeRush, Refactor!Pro, or any other third-party refactoring tool you might prefer…ahem!…Resharper…)
As described in this issue, there had been some challenges around the use of wildcards in the pattern-matching filter string in v1.0. This was largely because I had chosen the pattern matching be applied using StartsWith(pattern) semantics (which meant that to get a match on something that contained the pattern, a user had to leverage wildcarding to filter the tree as desired). The filter behavior has now been changed to apply Contains(pattern) semantics which should remove the need for wildcards in the filter string. Hopefully this will result in a more useful (and powerful) filtering-by-partial-name capability.
Coming Soon: Option for All Open Documents in the Tree
As you can see from this issue, I have just about got the work prototyped to support the option to display the treeview nodes for all open documents in the Visual Studio editor at the same time (rather than just the treeview containing the current active document’s elements). Since often developers will open 2-3 related documents in the editor at once in order to perform some task (TDD is the canonical example, but I can think of many more in my daily work) this feature (when toggled ON) will permit the display (and more importantly, the filtering) of the treenodes for all open documents in the single SourceOutliner treeview.
As shown in the screenshot at left, this will be achieved by introducing a higher-level ‘document node’ at the level above that of the ‘namespaces’ (presently the highest level node displayed in versions up to v1.1). More importantly, once completed, this feature will apply filtering across all elements from all open documents, permitting developers to do useful things like showing only Class and Interface declarations from all open editor documents and then quickly navigate between them from the treeview using the same single-click-to-nav/double-click-to-nav-plus-set-focus capability the treeview exposes now.
This capability is already in the TRUNK of the code in the Google Code site, but its in a prototype-only stage now where its both forced always-active (no facility is yet provided to toggle it on/off) and also not regression-tested against the rest of the system to ensure nothing major is broken by this new feature.
None the less, if anyone wants to grab the trunk, build it, and experiment with this new feature, I’d be glad to take early feedback as I work to flesh the rest of it out.
As always, if there are any bugs, comments, ideas, etc. that you think would help to improve this tool, please either leave a comment here or open a new issue at the Google Code site.
Happy coding~! 🙂