Rubberduck: AutoSave causes code pane to lose focus

[bbarney213]

After installing Rubberduck I have a persistent issue where the IDE will change focus from the editing window. Initially it would set focus to the Project Explorer window. When I removed the project explorer window in favor of the Code Explorer window, the focus would then set on the properties window instead. I removed this window as well, and now I have no clue where the focus is going, but the issue persists.

This issue happens very frequently to the point that I can enter about a few lines 9max, and if I get lucky) before I lose focus. I have attached a video of the issue (working with Mat's Mug on SO to resolve the issue, so forgive me for the pauses and the check on key hooking).

Heres a link to the video: https://www.dropbox.com/s/6ussrc3wrfxjpm2/Rubberduck%20Losing%20Focus.webm?dl=0.

I apologize if more detail is needed. I am not sure what is happening precisely, so I don't know how to reproduce the issue.

[retailcoder]

Not sure if the logs might contain useful information... try setting minimum log level to TRACE and then reproduce the issue; the log will be very verbose, but there's a slight chance we might be logging something that gives us a clue.

[bbarney213]

Here's the log.
RubberduckLog.txt

[retailcoder]

Interesting:

2017-04-25 09:21:19.7591;INFO-2.0.13.32288;Rubberduck.App;Rubberduck version 2.0.13.32288 loading: Operating System: Microsoft Windows NT 6.1.7601 Service Pack 1 x64 Host Product: Microsoft Office 2013 x64 Host Version: 15.0.4420.1017 Host Executable: EXCEL.EXE; 2017-04-25 10:57:21.1969;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (T) not registered.; 2017-04-25 10:57:21.1979;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (C) not registered.; 2017-04-25 10:57:21.1979;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (R) not registered.; 2017-04-25 10:57:21.1979;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (E) not registered.; 2017-04-25 10:57:23.9956;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.ParentMenus.ParentMenuItemBase;(39767165) Executing click handler for menu item 'S&ettings', hash code 57710802; 2017-04-25 10:57:52.7709;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (T) not registered.; 2017-04-25 10:57:52.7709;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (C) not registered.; 2017-04-25 10:57:52.7709;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (R) not registered.; 2017-04-25 10:57:52.7739;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (E) not registered.; 2017-04-25 10:58:10.0522;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.ParentMenus.ParentMenuItemBase;(39767165) Executing click handler for menu item 'S&ettings', hash code 4156611; 2017-04-25 10:58:22.2736;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (T) not registered.; 2017-04-25 10:58:22.2756;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (C) not registered.; 2017-04-25 10:58:22.2756;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (R) not registered.; 2017-04-25 10:58:22.2756;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (E) not registered.; 2017-04-25 10:58:34.9081;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (T) not registered.; 2017-04-25 10:58:34.9081;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (C) not registered.; 2017-04-25 10:58:34.9081;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (R) not registered.; 2017-04-25 10:58:34.9081;DEBUG-2.0.13.32288;Rubberduck.Common.Hotkeys.Hotkey;Hotkey (E) not registered.; 2017-04-25 10:58:59.6540;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.ParentMenus.ParentMenuItemBase;(39767165) Executing click handler for menu item 'S&ettings', hash code 13863750;

Seems like there is something fishy going on with the hotkeys.

[bbarney213]

Here's one with only one instance of it happening. Seems like something is happening with hotkeys indeed (I couldn't fix the issue by typing super slow though).
RubberduckLog.txt

Also, captain obvious here, but is there any change that the "Rubberduck.Ui.Command.MenuItems" is the event actually changing the focus? From my limited ability to open the log immediately after the event and to immediately check the system clock, it seems as though it isnt the hotkey changing focus, but the event that follows. Its almost as though Rubberduck is trying to clean up in a sense?

[retailcoder]

2017-04-25 10:58:59.6540;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.ParentMenus.ParentMenuItemBase;(39767165) Executing click handler for menu item 'S&ettings', hash code 13863750;

That's just the "Settings" command/menu item logging a click - the command pops up the settings dialog, which is modal and thus gets the focus indeed.

I notice the log starts at 9:21; RD starts up but doesn't proceed with the initial parse, and then nothing happens for about 90 minutes? IIRC the VBE hooks don't get enabled until the initial parse completes... try saving any changes, closing everything, verifying that there's no EXCEL.EXE process lingering in task manager (kill any that shouldn't be there), and re-starting Excel/Rubberduck.

[bbarney213]

RubberduckLog.txt

No such luck. The same issue (almost immediately after starting to type. I declared one variable and was in the middle of declaring the second). The log is much bigger, but I imagine this is the startup stuff,

[Inarion]

Hi there,
I just registered since I wanted to share my experiences on this issue.
I had our IT install RD for me and I immediately recognized the focus switching described by @bbarney213 earlier. (It may have been as obvious to me as I was browsing the issues list while waiting for the IT guy to come back to me.)

My observations:

• With TRACE logging activated, it seems that the focus switching is not actually logged (see below: Between 14:52:05 and 14:54:35 I clicked several times into my source code only to have the focus repeatedly switch to select my active project in the project explorer. I did not perform any other action within that time frame.)
• There seems to be a set interval of exactly 10s for when the switching happens. The interval seems to be independent of my actions: e.g. I click into my code after the switch happened, then 10s later it switches. I then wait 5s before clicking into my code again, after which it takes 5 more seconds for the focus to switch again (10s after the last switch).

Here an excerpt of the relevant log file. (I removed several thousand lines of parser DEBUG and TRACE messages.):

2017-05-03 14:51:06.5039;INFO-2.0.13.32288;Rubberduck.App;Rubberduck version 2.0.13.32288 loading:
    Operating System: Microsoft Windows NT 6.1.7601 Service Pack 1 x64
    Host Product: Microsoft Office 2010 x86
    Host Version: 14.0.7176.5000
    Host Executable: EXCEL.EXE;
2017-05-03 14:51:06.8970;INFO-2.0.13.32288;DynamicInjectorc0045f2756d7437d82e2d625c33849a4;Executing version check.;
[... here I deleted some lines...]
2017-05-03 14:52:05.7423;TRACE-2.0.13.32288;Rubberduck.UI.Inspections.InspectionResultsViewModel+<RefreshInspections>d__69;Inspections loaded in 46786ms;
2017-05-03 14:54:35.8899;DEBUG-2.0.13.32288;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;(42927366) Executing click handler for commandbar item '2 references', hash code 51397302;
2017-05-03 14:54:35.9099;TRACE-2.0.13.32288;Rubberduck.UI.DockableToolwindowPresenter;Initializing Dockable Panel (SearchResultsDockablePresenter);

If I can provide you with more information, I'll be more than happy to assist.

[retailcoder]

I just installed the 2.0.13.32288 build to try and reproduce this issue... no luck. Somehow I get no inspection results either, inspection results toolwindow just keeps reporting a "busy" state but no inspection work appears to ever get done - I'm setting this inspection issue aside since with the changes made since the .13 release inspections should be much more reliable (being triggered directly by the parse coordinator), but I have no idea how to reproduce this focus-shifting issue.

[Inarion]

Well, stupid me. When setting up RD on my work PC, I was wondering what unit the autosave feature might have, but activated it nonetheless. (With the default value 10)

Now, at home, I installed RD (for the first time on this PC, which is also quite different hardware- and software-wise) and the only thing I did was to go to the options and replicate my RD options at work as well as I could.
And - tada! - after confirming the settings I had the focus switching again (not before though). And - coincidentally - also with an exact timing of 10s. Coincidence really? No. Deactivating the autosave option also got rid of the focus getting lost.

So what I take from this:

1. Autosave is measured in seconds, not minutes as I assumed.
2. The autosave feature seems to have problems to properly focus. At least on the two machines I tested.

Maybe you can reproduce the issue with this information?

[retailcoder]

@MDoerner dang, you were right!

I'm leaning towards simply killing the "autosave" feature.

[rubberduck203]

Testivus say, "Some features cost more than they're worth."

[Inarion]

That seems to be an easy and effective solution. 👍

[MDoerner]

Can this be closed now that the auto save feature has been removed?

[Vogel612]

@MDoerner closed in #2998