Improve capturing keystrokes on invoking Favourites.
jasonjac2 opened this issue · 13 comments
Problem to Solve
My ON is littered with "dai" as I press Alt+F to got favourites and start typing dai for "daily/weekly/monthly" to be presented with the favourites screen with nothing in the filter box.
New Feature/Solution
Would it be possible to capture the keyboard earlier in the invocation and play those keys into the filter edit?
Alternative Solutions
I type slower :-(.
Additional Context
I have about 6 ON pages open and jump around a lot - I am a KB warrior and use Windows+1 as ON is 1st on my taskbar, so Windows +1 x 1 = left most ON, Windows +1 x 2 = 2nd ON on the main screen.....
I have about 20 - 30 favourites and know the 3 letters that gets each one.
Also, making the favourites screen super keyboard navigation would be good. ctrl+1 = 1st item, enter always opens the focus row or if no focus the top row.
The keyboard focus is set to the Alt+F text field as soon as possible. On my piddly little laptop, I can't react fast enough after pressing Alt+F to not type in that text field.
Does this happen just the first time the Favorites dialog is opened after starting OneNote, or every time?
2 different laptops, everytime. one W10, one W11, both about 4 years old. one Dell Precision meaty laptop. I can try and record a demo at some-point.
I might also try and record an autohotkey with different delays to see how long it actually takes.
" as soon as possible. " sounds like a challenge :-).
I don't really know the event model for C# WPF. When does it hook into the keystrokes?
How about a standalone exe for fav's?
Aside: just rearead - none of this is a criticism, just one of those - get something down quickly. As always LOVING the product.
The object/event model starts with a COM surrogate layer. When OneNote starts up, it also starts a separate DLLHost.exe process to host the plugin (one per different plugin if you have multiple.) That DLLHost process exists for the lifetime of the OneNote session.
Being COM, it has a pretty close trusted relationship with the main OneNote process and can react pretty quickly. Compare that toa separate exe that would need to spin up and then rely on some other interop mechanism to communicate with the OneNote process, such as named pipes or REST or, well, a custom COM layer.
The dialog's event sequence is to first read the Favorites.xml file to populate the UI (OnLoad event), and then set focus on the text box (OnActivated event). So the only thing slowing it down might be a mechanical hard drive waiting to seek into position to read the XML file.
As far as I know, you can't set focus on a control until after the built-in OnActivated event (OneMore uses WinForms, not WPF)
BTW, a more technical dive into the signaling flow between OneNote and its COM surrogates is shown in my Interop article
@stevencohn thanks for the link. So there is processing before the OnActivated. I remember you removing the "invalid links" from the Favourite dialogue, so it only shows in the maintain fav's.
I thought I would test on a PC that had 0 or 1 favourite to see if it was a function of the number of fav's.
I also have a monthly clean up and actually noticed that one of my 20 - 30 fav's is marked as yellow (in maintain fav's) and so the app thinks it is a broken link, eventhough it still navigates to the correct place (I assume I have moved the page and so the link has to do that try, try harder thing that OneNote seems to do). I deleted and re-added the link.
Unfortunately I rebooted my PC since and now the fav's is instant and I can't make it do the "keystrokes on the page" thing. I'll see if it deteriorates with time, i.e. some kind of accumulated slowness.
Can you confirm the loading the Fav's up into the list is nearly instant and there is no real processing done.
Regards,
Jason.
This is true. There is no business logic other than reading the file and building the UI.
Just keeping this alive. It appears to depend on how long my machine has been running. This is correlation vs causal as it may also be:
- How many ON "instances" I have open
- How many times I have invoked a OM tool
- Other load on system - VMs etc.
- ....
I have removed the one broken link (where Fav's maint highlighted it as yell, but selecting it took me to the correct page), but based on your description, that wouldn't cause a problem.
Since my last reboot, it has gone from 1:2 times to maybe 1:20 times of invokation.
I've noticed something similar happen in the Command Palette. If you start typing too early, either the focus is not set on the CP window or each keypress results in an unrecognized box character! My solution is to take half a breath before typing ;-)
I suspect it's due to lag in the COM layer between the add-in and OneNote. If that's the case, it's a support ticket to Microsoft and nothing I can do about it :-(
Hi, so sometimes the host page gets the keystrokes and sometimes they go nowhere and sometimes they hit the right target.
So a couple of suggestions:
- Logging - optional logging in system to log the invocation vs the completed timestamps - I assume logging is async (and so not going to get in the way), and it would allow a bit of rigour about how it changes over time. Would you be able to track this lag or at least as soon as your add-in is aware of it, before it has done ANY processing at all.
And of your:
- delay before typing - I live in a "pc-anywhere" era where you can just type ahead, otherwise slowing to the longest delay means a lot of waiting around :-). Maybe time for a new laptop or a slower me.
I see your change and followed through to native.cs -> windows help. Is this a test now you have a reproducible test?
Well, it fixed it for the Command Palette. I haven't been able to really repro it for Favorites, but the theory is the same.
Fantastic, so is there any chance of getting a sneaky peek version? Especially if I can relatively easily switch back and forth without a reboot to do an active comparison.
This should work... rename the old DLL and then save this to your OneMore program files folder