-
Notifications
You must be signed in to change notification settings - Fork 7.2k
cmdpal: move kb shortcut handling to PreviewKeyDown #40777
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This lets things like C-S-c work in the text box Closes #40174
@@ -255,6 +245,22 @@ private void FilterBox_PreviewKeyDown(object sender, KeyRoutedEventArgs e) | |||
_inSuggestion = false; | |||
_lastText = null; | |||
} | |||
|
|||
if (!e.Handled) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will make extension key-binding take precedence over built-in commands (Enter, Ctrl+Enter, Ctrl+K) and text box ones that should stay intact (Ctrl+C, Ctrl+V, Ctrl+A)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kinda, yea. Not really sure how we could square it otherwise. Either we handle the keybinding, or we let the OS/UI platform handle the keybinding.
It's probably not best practice for an extension to hijack Ctrl+C/V or things like that, but I'm not sure we can just have a deny-list of "keybindings you aren't allowed to set". Like if an listitem's context item takes over Ctrl+A, then... that's kinda what is expected based on what the author wanted, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thing the OPs problem was with CmdPal having the broad handling (text box handles Ctrl+Shift+C as Ctrl+C, or even KeyDown handler that handles anything with Enter - so it will eat up Ctrl+Shift+Enter by accident). By I feel allowing extension to override anything might lead to inconsistent ux. If one extension overrides Ctrl+A then select all in text box stop working for that extension/item, but will work for everyone else normally.
I think having list of reserved shortcuts is actually the right way to go.
My idea woukd be to have array of reserved chords, use that list to prevent passing those to 3p extensions. With doing exact march of the chord it will allow them to use everything else.
KeyChord primaryChord = Helper.Create(ctrl: true, vkey: Enter);
KeyChord[] reserved = [primaryChord];
KeyDown
..
var c = ChordFromEvent(e);
if(c == primaryChord) {}
PreviewKeyDown
..
if(!e.Handled &&!reserved.Contains(c)){...send message...}
But this can be handled later (or never). The current PR does a great job with handling the main issue. It just caught my attention, since I dealt with similar issues few times in the past.
Sorry about the form, I'm on the move today.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dann, that's long! So, let's make it longer.
I had two additional thoughts With that array of chords:
a) it might be a nice heads up for customization;
b) I'd love to be able to use Ctrl+U/Down later, ideal for reordering items in the list O:)
This lets things like C-S-c work in the text box, and in the context menu too
Closes #40174