Skip to content

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

zadjii-msft
Copy link
Member

This lets things like C-S-c work in the text box, and in the context menu too

Closes #40174

@@ -255,6 +245,22 @@ private void FilterBox_PreviewKeyDown(object sender, KeyRoutedEventArgs e)
_inSuggestion = false;
_lastText = null;
}

if (!e.Handled)
Copy link
Contributor

@jiripolasek jiripolasek Jul 23, 2025

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)

Copy link
Member Author

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?

Copy link
Contributor

@jiripolasek jiripolasek Jul 24, 2025

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.

Copy link
Contributor

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:)

@zadjii-msft zadjii-msft added Product-Command Palette Refers to the Command Palette utility In for .93 labels Jul 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
In for .93 Product-Command Palette Refers to the Command Palette utility
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CmdPal some keys cannot be used for RequestedShortcut
2 participants