Rubberduck UI submenus are disabled

Question

I've just installed the Rubberduck VBE add-in v2.0.11.2453 (MSIL) on Windows 10 OS.

When I open a macro-enabled Excel workbook in Excel and launch the VBA editor, Rubberduck starts but all commands under the Rubberduck menu are disabled.

What am I doing wrong?

Answer 1

Disclaimer: I'm heavily involved with the development of the Rubberduck add-in.

You did nothing wrong =)

In earlier alpha 2.x releases we discovered that launching the initial parse on startup was causing problems (violent crashes), because the add-in was, essentially, ready before the VBE had finished setting up the object model for the project(s) loaded in the IDE. Basically the VBE loads its add-ins before it completely finishes constructing itself, so we can't just launch a parse task right on startup.

So we disabled the initial/automatic parse, that's why it needs to be done manually (for now).

The Rubberduck commandbar (docked at the top of the IDE by default, just below the main commandbar) contains a "refresh" button:

Clicking that button will change the parser state from "Pending" / "En attente" to "Ready" / "Prêt" (after going through a number of states).

Most Rubberduck commands will be enabled as soon as the state is "Parsed" (which doesn't last very long - it switches to "Resolving identifiers" quite immediately after), and the refactorings get enabled on "Ready" state (even before inspections finish running).

You will also find that "refresh" command button in the toolstrip of the Code Explorer, Test Explorer, Inspection Results and Todo Explorer toolwindows.

You should be able to browse/navigate the code and use the VBE while Rubberduck is working in the background, but please note that modifying code while Rubberduck is parsing it is possibly going to result in some parser error states; we assume that the code in the IDE is compilable =)

Think of that button as "Okay ducky, I've done code changes, now sync up with the IDE": the add-in needs to know the exact in-editor location of every single token in order to work as it should. Refactoring or applying an inspection quick-fix on de-synchronized parser state is definitely a bad idea!

That said, disabling all menus on startup was kind of lazy (and clumsy too: for example the hotkey for displaying the inspection results and code explorer toolwindows will work even though the menus are disabled) - we'll fix that by next release, and the initial parse should be automatic again, too (we'll make it start after a delay, to give the VBE a chance to finish starting up).