Rubberduck: Crash when hitting CTRL+G to open VBE in Access

[wsrob]

Access allows you to press CTRL+G to launch the VBE which puts focus in the Immediate window. This is a carryover from previous Access versions. The Immediate window is in the CodePanes collection, but is not actually a CodePane, so GetCodePaneFromHwnd() returns null and crashes here:

        if (!pane.IsWrappingNullReference)

The repro is:

1. Launch Access and open a database.
2. Press CTRL+G

Here's the call stack:

Rubberduck.dll!Rubberduck.App.RefreshSelection(Rubberduck.VBEditor.SafeComWrappers.Abstract.ICodePane pane) Line 114    C#
 Rubberduck.dll!Rubberduck.App._vbe_SelectionChanged(object sender, Rubberduck.VBEditor.Events.SelectionChangedEventArgs e) Line 90 C#
Rubberduck.VBEditor.dll!Rubberduck.VBEditor.Events.VBEEvents.OnSelectionChanged(System.IntPtr hwnd) Line 139    C#
 Rubberduck.VBEditor.dll!Rubberduck.VBEditor.Events.VBEEvents.VbeEventCallback(System.IntPtr hWinEventHook, uint eventType, System.IntPtr hwnd, int idObject, int idChild, uint dwEventThread, uint dwmsEventTime) Line 71  C#

[ThunderFrame]

That doesn't seem right. I've just tried in Access XP and 2016, and both work with Ctrl+G, and both report Application.VBE.CodePanes.Count = 0 is True. Is there some other state-based thing? Do you have an ACCDB/MDB database open, do you have MDE/ACCDE add-ins loaded? Do you have unsaved forms/reports/modules?

[wsrob]

ACCDB, new database with 1 module. This happens with the latest bits after forking the project (2.0.12.3xxxx) and running it from VS2015.

@ThunderFrame , that's correct, it's actually not in the CodePanes collection - it's a Window that is being enumerated by RD which then tries to get a CodePane object for it. This fails because the Immediate window is not a CodePane.

[ThunderFrame]

Strike that, I can replicate this. And I can replicate it all hosts.

In Access, Ctrl+G crashes the host when pressed while Access is active.
In all hosts, Ctrl+G crashes the host when pressed while the VBE is active.

[comintern]

I can't replicate this on my build, but it shouldn't be difficult to add some more checks to make sure I got a window back. Can you confirm that you have PR #2698 in your build?

[comintern]

OK, I've replicated this now - pretty sure I have an idea of where to look.

[comintern]

This seems to be solved by a null check before raising SelectionChanged. I'll PR the fix over lunch, but it looks like this is all that it needs in VBEEvents:

        public static event EventHandler<SelectionChangedEventArgs> SelectionChanged;
        private static void OnSelectionChanged(IntPtr hwnd)
        {
            if (SelectionChanged != null)
            {
                var pane = GetCodePaneFromHwnd(hwnd);
                if (pane != null) SelectionChanged.Invoke(_vbe, new SelectionChangedEventArgs(pane));
            }
        }

[comintern]

This appears to have been resolved by the fix above.