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
            foreach (var result in e.ParseResults)
                var node = new TreeNode(result.Project.Name);
                node.ImageKey = "Hourglass";
                node.SelectedImageKey = node.ImageKey;

                AddProjectNodes(result, node);

    private void _parser_ParseStarted(object sender, ParseStartedEventArgs e)
        Control.Invoke((MethodInvoker) delegate
            foreach (var name in e.ProjectNames)
                var node = new TreeNode(name + " (parsing...)");
                node.ImageKey = "Hourglass";
                node.SelectedImageKey = node.ImageKey;


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 , but I'm not looking for code, I'm looking for concepts.

  • 2
    Just an FYI, we also have a UserExperience.SE site as well. I believe this is on-topic here because it is discussing code design more than user interface but I wanted to let you know in case your changes drift more toward the UI side and not the code/design side of the issue.
    – user22815
    May 8, 2015 at 14:56
  • When you are parsing, is this an all-or-nothing operation? For example: does a change in a file trigger a complete reparse, or only for that file and those that depend on it?
    – Morgen
    May 8, 2015 at 16:16
  • @Morgen there's two things: VBAParser is generated by ANTLR and gives me a parse tree, but the features don't consume that. The RubberduckParser takes the parse tree, walks it, and issues a VBProjectParseResult that contains Declaration objects that have all their References resolved - that's what the features take for input.. so yeah, it's pretty much an all-or-nothing situation. The RubberduckParser is smart enough to not re-parse modules that have not been modified though. But if there's a bottleneck it's not the with the parsing, it's with the code inspections. May 8, 2015 at 16:20
  • 4
    I think, I would do it like this: When the user triggers a refresh, that toolwindow triggers the parse and shows that it's working. The other toolwindow(s) are not notified yet, they keep displaying the old information. Until the parser finishes. At that point, the parser would signal all toolwindows to refresh their view with the new information. Should the user go to another toolwindow while the parser is working, that window would also enter the "working..." state and signal a reparse. The parser would then start over to deliver up-to-date info to all windows at the same time. May 8, 2015 at 16:47
  • 2
    @cmaster I would upvote that comment as an answer too.
    – RubberDuck
    May 8, 2015 at 16:57

1 Answer 1


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
      SET shouldParse TO true

    This will be paired with logic wrapping the parser, that may look something like this:

    SET parseIsRunning TO true
      SET shouldParse TO false
    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.

  • 1
    Excellent points, but I have a question: I'm using ParseStarted to disable the [Refresh] button (Control.EnableRefresh(false)). If I remove that callback, and let the user click it... then I'd put myself in a situation where I have two concurrent tasks doing the parsing... how do I avoid this without disabling refresh on all other functionalities while someone is parsing? May 8, 2015 at 18:01
  • @Mat'sMug I updated my answer to include that facet of the problem.
    – Morgen
    May 8, 2015 at 18:29
  • I agree with this approach, except that I would still keep a ParseStarted event, in case you do want to allow the UI (or other component) to sometimes warn the user a reparse is occurring. Of course, you may want to document callers should attempt to not stop the user from using the (about to be) stale current parse results.
    – Mark Hurd
    May 13, 2015 at 1:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.