Open n-heartstrings-sterling opened 2 years ago
If I was to take a guess, the issue exists around lines 2337 and 2354 of the log file
2021-10-07 10:29:19.4118;TRACE-2.5.2.5906;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;CancellationTokenSource was already disposed for OnSelectionChange.;
2021-10-07 10:29:19.4118;INFO-2.5.2.5906;Rubberduck.UI.Command.MenuItems.CommandBars.AppCommandBarBase;System.Threading.Tasks.TaskCanceledException: A task was canceled.
Which I figure, as someone who's entirely unfamiliar with the codebase, might imply ignoring the mouseUp event
Hm, not sure how that could happen.. these log entries stem from a cancelled attempt (could be because another event came in by the time the handler entered) to update the commandbar labels and commands accordingly with the current selection changing, captured by our OnSelectionChange
event... in response to the current selection changing.
We do have navigation commands that can alter the current selection in the editor, but none of it seems to be at play here. So that's... interesting.
Quick update here - I'm almost certain that it's just plain old lag. When holding down an arrow key, there's a visible stutter. It's worse the more dense the number of calls and expressions.
Here its quite minor, and only really stutters around the assignment operator https://user-images.githubusercontent.com/84310111/136503345-64d7f7b4-0f3b-428e-ba70-37a675982f53.mp4 In a more common case of many chained method calls, it stops constantly (every comma, period, and bracket etc)
I've swapped over to legacy workload configuration, but the performance issues persist. I guess there's some kind of bottleneck? certainly not on the hardware end.
Ah, assuming you had the autocompletion features enabled, holding down the arrow key would probably do it - when that's enabled, Rubberduck not only picks up selection changes, but also needs to start handling individual keypresses. Successive arrow-key presses shouldn't be a problem then, but consider using page up/down, mousewheel scrolling, ...or turning off autocompletion in Rubberduck settings: when enabled autocompletion does change a bit how we work in the VBE (esp. with keyboard navigation, and when typing strings and parentheses), and needs a bit of an adaptation to get used to the behavior. Hope it helps!
Edit: actually autocompletion enabled or not holding down any key that affects the current selection would quickly fire up selection changed events, and likely could induce a noticeable lag. OnSelectionChange handlers involve getting the current selection (from the VBIDE API / COM interop), updating the command bar accordingly, and then every menu command needs to evaluate whether it should be enabled or not - that said it doesn't really explain the apparent left-button capture.
Yes, as I've found, turning off autocompletion features didn't seem to fix the issue. It's pretty clear that the mouse clicking issue is some kind of lag-induced loss of the mouseUp event through a race condition or similar, but I'm not sure what or how. It's very possible that this issue would occur in an unmodified VBE given the right latency at the right time
Just chiming in - seeing the same issue - I can't offer specifics about the environment since I restarted Excel, but I had 3 workbooks open, 2 add-ins, and a large userform project open with hundreds of control objects etc. I was in the RD menu bar looking at something in the refactor menu, then went to the code section and it started selecting blocks when I clicked. Not sure what else to offer. Using Excel 365 latest version.
Rubberduck version information Rubberduck version 2.5.2.5906 loading: Operating System: Microsoft Windows NT 10.0.19043.0 x64 Host Product: Microsoft Office x64 Host Version: 16.0.14530.20000 Host Executable: EXCEL.EXE;
Description After (and only after) refreshing using Rubberduck, every second click will inconsistently act as if the mouse is being held down, causing a selection to expand as the mouse moves. On the second click, the selection will remain, A subsequent click will cause a selection to be made towards the cursor, and so on. This only seems to occur in complex user forms.
To Reproduce Steps to reproduce the behavior:
For i = 1 To 1 Stop Next
insteadExpected behavior The cursor should move without making any selections
Screenshots You'll have to take my word for it - at no point during this recording am I holding down the mouse https://user-images.githubusercontent.com/84310111/136296711-4ad6a2db-d87c-42ae-ad5e-80bf69644618.mp4
Logfile Opened existing file with above setup, opened the VBE, refreshed and enabled code explorer, opened userform code, refreshed and clicked around until it occurred once, continued until it occurred a second time, closed file. RubberduckLog.txt
Additional context This is a fresh install of 21H1 and 365 Beta from ODT. I was previously using Windows 10 LTSC with 365 Current without issue. (nb: VBE colors are changed using regedit and changing the palette values in VB7.dll with a hex editor)