Add initial hooks for keyboard-related events. #57
Conversation
Long-overdue contributor recognition.
| // fallback, the context menu can't receive keyboard events - should not happen though | ||
| WinApi.SetForegroundWindow(handle); | ||
|
|
||
| ContextMenu.Focus(); |
There was a problem hiding this comment.
I'd like to understand why you have added a focus, can you add some comment here?
There was a problem hiding this comment.
I still would like to know why you think this is needed, was there some kind of issue without it?
There was a problem hiding this comment.
Without this line, the context menu doesn't have keyboard focus after being displayed (at least on Windows 11), so navigation with the arrow keys doesn't work, and you can't even close the context menu with Escape. This line should definitely be merged into the main branch, even without the rest of the patch.
|
Looks like a very good PR, much nicer as I could have made as I am not the best routed event etc WPF programmer. |
|
The only thing which surprised me was that by default the keyboard does nothing. Wouldn't it make sense to wire up the defaults? |
|
I tried to merge the most recent changes, but couldn't modify it, so I created a PR for it. It was a lot of manual work, so I hope I didn't screw up... |
4 participants
This is the first step to implement keyboard interaction using the standard Win+B, Ctrl+F10, Enter, etc. shortcuts.
Going further will require more work:
WM_CONTEXTMENUcan open the context menu next to the icon rather than under the mouse cursorNIN_KEYSELECTbeing received twice in a row (when Enter is used), maybe using a timer similar toTaskBarIcon.singleClickTimer