In this recent post I blogged a bit about some of the limitations of the otherwise very valuable Visual Studio Source Code Outliner PowerToy add-in. I also posted about my intent to hack together a supped-up replacement for the thing that leverages the capabilities of the Developer Express DXCore Visual Studio API abstraction layer to make my job as a Visual Studio add-in developer simpler. I’m happy to announce that after about 15 hours of on-again/off-again work, the first public ALPHA preview release of the add-in is ready to be made available for testing/evaluation.
Downloading and installing the DX_SourceOutliner
You can get the binary of the present build as a ZIP file here.
As mentioned the DX_SourceOutliner requires the DevExpress DXCore runtime library to be present in your Visual Studio installation so if you haven’t already you will need to first download and install ONE of the following Developer Express Visual Studio Extensibility/Productivity Tools:
Since all of these contain (and are based on) the DXCore runtime at their heart, any one of these (including any of the FREE ones) will suffice in order to run the DX_SourceOutliner add-in.
Once you have downloaded the ZIP file and installed one of the above DXCore-based products from DevExpress, copy the single binary extracted from the ZIP file into your DXCore plugins folder (usually My Documents\DevExpress\IDE Tools\Community\PlugIns unless you have changed the default).
Once you install the DX_SourceOutliner binary (by copying it to the proper plugins path as above), you can open the tool window in Visual Studio by selecting DexExpress menu –> Tool Windows –> DX Source Outliner. Once the window is opened, you can dock it, pin it, roll it up, etc. as desired.
Getting the DevExpress Menu to Appear in Visual Studio
Depending on the installed DevExpress components, you may or may not have the DevExpress menu displayed in Visual Studio.
From my experience, if you have the COMMERCIAL offerings installed the DevExpress menu is displayed but if you only have the FREE offerings installed the menu is NOT displayed by default. If you do not see the DevExpress menu in Visual Studio, follow the instructions towards the bottom of this DevExpress forum post to set the menu to display for you in Visual Studio. Once you make the suggested registry change and restart Visual Studio you should have the menu displayed and the DX_SourceOutliner listed as an available tool window to open.
I’m researching (but haven’t yet found) a way to somehow get a DXCore ToolWindow (like the DX_SourceOutliner’s) to display without the user having to set the DevExpress menu visible, but I’m not certain such a solution even exists so this is likely to remain a nuisance for any users of the DevExpress FREE offerings (sorry; I don’t write the APIs, I just use them~!)
A Quick Tour Around What’s Done
Generating the TreeView
As shown in the following screenshot, the basic UI is largely completed and the core functionality of building and displaying the tree itself is largely completed.
As of now, the only ‘types’ that are rendered in the tree are Namespace, Class, Method, and Variable (field) but that was enough to get the core tree-building code fleshed out; the other types (Interfaces, Delegates, Events, Structs, etc.) are still to come but will be simple to extend into the tree rendering model that’s already developed.
Controlling Information Display for Each Node
As shown in the next screenshot, the ‘Filter Details Panel’ is expanded to show the three buttons that control the display of the contents in the tree:
- show return types
- show parameter names
- sort elements alphabetically instead of ‘structurally’
There are labels for where the Member, Types, and Access (visibility) filter buttons are to be added, but filtering (in general) is not yet implemented and so there aren’t yet toggle buttons here:
As of now, only the first two, ‘Show Return Types’ and ‘Show Parameter Names’ are implemented and you can see their effects in the following screenshot:
Note the return types are displayed in the format of “: <dayatype>” suffixed on the end of the element where appropriate so that the element name itself remain the beginning of the text for each node of the tree (making it simpler to scan the list). Also note that with the ‘Show Parameter Names’ toggled ‘on’ the actual name of each parameter in each method is displayed instead of just the datatype for each parameter as is the default (and only choice with the Source Outliner PowerToy).
Filtering ‘Flattens’ the TreeView
The following screenshot shows the only thing that (currently) happens when you check the box to enable Filtering on the tree’s contents: the tree ‘flattens’ itself into more of a ‘list view’ (even though under the hood its still a TreeView control) in preparation to have filtering applied to the list. As mentioned in my prior post, filtering will consist of the intersection of the Types, Members, Accessibility (public, private, etc.), and the text entered into the Filter textbox.
A Quick List of What’s NOT Done
From my original ideas about this thing, there are several minor (and a few) major remaining implementation items that I need to address…
- Filtering of TreeNodes; currently there is NO filtering code implemented yet at all; filtering is to include the caps-equal-pascal-case-search feature
- Sort TreeView list alphabetically; the toggle button for enabling this is present, but clicking it does nothing as of now
- Add support for all the other types of elements (Events, Delegates, etc.); presently only a few types of nodes are rendered in the tree thus far
WARNING, WARNING, WARNING: this release is early ALPHA and is intended only for evaluation and feedback purposes; the RTM will probably be by the end of this week, but in its present state its NOT intended to be used for production purposes — USE AT YOUR OWN RISK!
Wish-List (v2.0?) Items
Following is my (growing) list of wish-list items that probably won’t make the initial 1.0 RTM release but are at least under consideration for the future
- switch the text in the treeview to owner-draw so that I can apply syntax coloring to the elements (e.g., DoWork (Customer customer) : void instead of just DoWork (Customer customer) : void) as well as simulate the same kind of pattern-match-syntax-highlighting that the CodeRush QuickNav tool offers for pascal-case-matching in the list (see this post for a screenshot of this in action in the QuickNav tool)
- permit saving of user settings for the treeview display options
- find a way to (somehow) invoke refactorings from the TreeView without taking a direct dependency on any COMMERCIAL DevExpress offering (am committed to ensuring the DX_SourceOutliner retains a dependency only on FREE DevExpress libraries at this point)
If you have any comments or feedback on this tool, please feel free to leave a comment here or e-mail me directly at the ‘Contact Me’ link in the RH sidebar of my blog.