ModifierKey / Key incompatible with VS

[LeeMSilver]

Both ModifierKey and Key in the Microsoft.VisualStudio.Extensibility.Commands namespace are incompatible with Visual Studio (VS) - they do not accept all keys and key-combinations that VS does.

1. ModifierKey -VS does not differentiate between the Left Alt and Right Alt keys. When a shortcut is entered manually, pressing either Alt results in Alt being displayed and either can be pressed as part of the shortcut. Also, in the .vsct'-file one specifies"Alt"`.

   -The first/only shortcut key must have a modifier of Alt and/or Control. Shift may be optionally added - it cannot be the only modifier.

2. Key -Key does not define the 0-9 keys (on the standard keyboard, not the NumPad). These are all allowed by VS.

   -The optional second shortcut key: a) can have no modifier b) can have modifiers specified in the same way as the first shortcut key with the same limitation on the Shift key.

[RyanToth3]

Thank you for the feedback!

Let me reiterate your points to make sure that I understand them correctly:

1. VS does not differentiate between the Left Alt and Right Alt keys.

This isn't the case. Visual Studio only allows you to execute a command using the Left Alt. It has been this way since I believe dev15 but I could be wrong about when exactly that fix was implemented. Although VSCT allows you simply specify Alt for a key binding, under the hood only Left Alt can actually be used to execute the key binding. We designed the new API to be more clear about this fact. Originally, Visual Studio did allow either Alt to be used which is why VSCT simply specifies Alt.

2. The first/only shortcut key must have a modifier of Alt and/or Control. Shift may be optionally added - it cannot be the only modifier. This is also true for the second modifier key. The first modifier key also cannot be None.

Great catch! I'll make sure to update our APIs to reflect that.

3. Key does not define the 0-9 keys (on the standard keyboard, not the NumPad). These are all allowed by VS.

Another great catch, I'll make sure to add those.

[LeeMSilver]

Note that I've already remapped my RightAlt to LeftAlt giving me 2 LeftAlts Thanks

Lee

On Thursday, February 29, 2024 at 10:39:00 AM GMT+8, Ryan Toth ***@***.***> wrote:  

Thank you for the feedback!

Let me reiterate your points to make sure that I understand them correctly:

• VS does not differentiate between the Left Alt and Right Alt keys. This isn't the case. Visual Studio only allows you to execute a command using the Left Alt. It has been this way since I believe dev15 but I could be wrong about when exactly that fix was implemented. Although VSCT allows you simply specify Alt for a key binding, under the hood only Left Alt can actually be used to execute the key binding. We designed the new API to be more clear about this fact. Originally, Visual Studio did allow either Alt to be used which is why VSCT simply specifies Alt.

• The first/only shortcut key must have a modifier of Alt and/or Control. Shift may be optionally added - it cannot be the only modifier. This is also true for the second modifier key. The first modifier key also cannot be None. Great catch! I'll make sure to update our APIs to reflect that.

• Key does not define the 0-9 keys (on the standard keyboard, not the NumPad). These are all allowed by VS. Another great catch, I'll make sure to add those.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[LeeMSilver]

First, I mis-wrote what modifiers are allowed for second (optional) key -- the second key can have a stand-alone Shift-key.

LeftALT: I know that I have been using Right Alt since 2010. Almost all the 80+ commands in my extension are activated w/ plain Alt. I believe there are 2 reasons to keep Right Alt - even though it can be remapped to Left Alt (which I'm sure 1) many don't know how to do, and 2) another application may use Right Alt.

1. Left-handed coders, like myself, use the mouse/pointing device with their left-hand making that hand inconvenient for the Alt and Ctrl kwys- that leaves the Right Alt (or Right Ctrl) as the most convenient key for for entering a shortcut.
2. Much less important, but consistency. You don't differentiate between Left Ctrl and Right Ctrl - so why between the 2 Alt keys.

-- Lee

[zivkan]

so why between the 2 Alt keys.

Just a guess, but this is a thing in several languages: https://en.wikipedia.org/wiki/AltGr_key

[RyanToth3]

so why between the 2 Alt keys.

Just a guess, but this is a thing in several languages: https://en.wikipedia.org/wiki/AltGr_key

Yes, Right Alt being mapped to AltGr in certain keyboard layouts is exactly why we don't allow Right Alt to be used in shortcuts. We've had issues in the past with keyboard shortcuts swallowing keyboard inputs that should result in a character being written to the editor when RIght Alt was allowed.

Remapping Right Alt to Left Alt on your keyboard sounds like a great work around for this limitation.

[LeeMSilver]

Ryan/Zivkan

OK. I understand the rationale behind LeftAlt.

I assume at some point in the future VS will dis-allow the RightAlt button for specifying Modifiers (it currently allows it). I sincerely hope that sometime before this happens all VS users are informed so they are not suddenly confused why when they press the RightAlt key their shortcut is not invoked.

[LeeMSilver]

I updated the NuGet packages for 17.11, including ModifierKey and a more serious problem now exists.

The following

      Shortcuts = [new CommandShortcutConfiguration(ModifierKey.LeftAlt, Key.C, ModifierKey.None, Key.U)],

now causes

CEE0005 An issue was encountered when evaluating the compile-time constant LMS.Formatter.CommandUndoCommand.CommandConfiguration. Unexpected error when evaluating compile-time constant value: Either both or neither second ModifierKey and Key should be None (Parameter 'key2').

ModifierKey.None should always be allowed as a modifier for the second key.

To make matters worse, my original workaround

      Shortcuts = [new CommandShortcutConfiguration(ModifierKey.LeftAlt, Key.C, ModifierKey.Shift, Key.U)],

fails because ModifierKey.Shift was removed as part of the ModifierKey update.