I’m writing a COM add-in that’s extending an IDE that desperately needs it. There are many features involved, but let’s narrow it down to 2 for the sake of this post:
- There’s a Code Explorer toolwindow that displays a treeview that lets the user navigate modules and their members.
- There’s a Code Inspections toolwindow that displays a datagridview that lets the user navigate code issues and automatically fix them.
Both tools have a “Refresh” button that starts an asynchronous task that parses all the code in all opened projects; the Code Explorer uses the parse results to build the treeview, and the Code Inspections uses the parse results to find code issues and display the results in its datagridview.
What I’m trying to do here, is to share the parse results between features, so that when the Code Explorer refreshes, then the Code Inspections knows about it and can refresh itself without having to redo the parsing work that the Code Explorer just did.
So what I did, I made my parser class an event provider that the features can register to:
private void _parser_ParseCompleted(object sender, ParseCompletedEventArgs e)
{
Control.Invoke((MethodInvoker) delegate
{
Control.SolutionTree.Nodes.Clear();
foreach (var result in e.ParseResults)
{
var node = new TreeNode(result.Project.Name);
node.ImageKey = "Hourglass";
node.SelectedImageKey = node.ImageKey;
AddProjectNodes(result, node);
Control.SolutionTree.Nodes.Add(node);
}
Control.EnableRefresh();
});
}
private void _parser_ParseStarted(object sender, ParseStartedEventArgs e)
{
Control.Invoke((MethodInvoker) delegate
{
Control.EnableRefresh(false);
Control.SolutionTree.Nodes.Clear();
foreach (var name in e.ProjectNames)
{
var node = new TreeNode(name + " (parsing...)");
node.ImageKey = "Hourglass";
node.SelectedImageKey = node.ImageKey;
Control.SolutionTree.Nodes.Add(node);
}
});
}
And it works. The problem I’m having, is that… it works – I mean, when the code inspections get refreshed, the parser tells the code explorer (and everyone else) “dude, someone’s parsing, anything you want to do about it?” – and when parsing completes, the parser tells its listeners “guys, I have fresh parse results for you, anything you want to do about it?”.
Let me walk you through an example to illustrate the problem this creates:
- User brings up the Code Explorer, which tells the user “hold on, I’m working here”; user continues to work in the IDE, the Code Explorer redraws itself, life is beautiful.
- User then brings up the Code Inspections, which tell the user “hold on, I’m working here”; the parser tells the Code Explorer “dude, someone’s parsing, anything you want to do about it?” – the Code Explorer tells the user “hold on, I’m working here”; user can still work in the IDE, but can’t navigate the Code Explorer because it’s refreshing. And he’s waiting for the code inspections to complete, too.
- User sees a code issue in the inspection results they want to address; they double-click to navigate to it, confirm there’s an issue with the code, and click the “Fix” button. The module was modified and needs to be re-parsed, so the code inspections proceed with it; the Code Explorer tells the user “hold on, I’m working here”, …
See where this is going? I don’t like it, and I bet users won’t like it either. What am I missing? How should I go about sharing parse results between features, but still leave the user in control of when the feature should do its work?
The reason I’m asking, is because I figured that if I postponed the actual work until the user actively decides to refresh, and “cached” the parse results as they come in… well then I’d be refreshing a treeview and locating code issues in a possibly stale parse result… which literally brings me back to square one, where each feature works with its own parse results: is there any way I can share parse results between features and have a lovely UX?
The code is c#, but I’m not looking for code, I’m looking for concepts.
10
The way that I would probably approach this would be to focus less on providing perfect results, and instead focus on a best-effort approach. This would result in at least the following changes:
-
Convert the logic that currently starts a re-parse to request instead of initiate.
The logic for requesting a re-parse may end up looking something like this:
IF parseIsRunning IS false startParsingThread() ELSE SET shouldParse TO true END
This will be paired with logic wrapping the parser, that may look something like this:
SET parseIsRunning TO true DO SET shouldParse TO false doParsing() WHILE shouldParse IS true SET parseIsRunning TO false
The important thing is that the parser run until the most recent re-parse request has been honored, but no more than one parser is running at any given time.
-
Remove the
ParseStarted
callback. Requesting a re-parse is now a fire and forget operation.Alternately, convert it to do nothing other than show a refreshing indicator in some out of the way part of the GUI that does not block user interaction.
-
Try to provide minimal handling for stale results.
In the case of the Code Explorer, that may be as simple as looking a reasonable number of lines up and down for a method the user wants to navigate to, or the nearest method if an exact name wasn’t found.
I’m not sure what would be appropriate for the Code Inspector.
I’m not sure of the implementation details, but overall, this is very similar to how the NetBeans editor handles this behavior. It is always very quick to point out that it’s currently refreshing, but also does not block access to the functionality.
Stale results are often good enough – especially when compared to no results.
3