Shift+key denied by text field as "control character" on remote systems

Describe the bug I cannot type any character with Shift modifier - no uppercase chars, no colon, no nothing. This does not happen on all systems.

To Reproduce Steps to reproduce the behavior:

1. Pull the Terminal.GUI
2. Start the unmodified UICatalog project
3. Put the cursor in any text input field
4. Type Shift+a - nothing happens
5. Type a - a is typed

Expected behavior I expect A to be typed when pressing Shift+a

Screenshots It seems like the key is discarded as “control character”. So the InsertText (kb) is never reached.

This does not happen on all systems, but on the one I have the debugger running ^^ Either the check should ignore the Shift modifier, or in an earlier step a conversion of Shift+a to uppercase A fails. Not sure how it is supposed to work.

(Note: removing the numlock modifier makes no difference.)

Here is the corresponding KeyEventRecord:

Desktop (please complete the following information):

• OS: Windows 11, English UI language, German keyboard language, through RDP session
• Version: relatively recent dev version: https://github.com/gui-cs/Terminal.Gui/commit/3866e65919ec67c1159162fb271f5f99fcf3a169

Additional context

Call stack:

>	Terminal.Gui.dll!Terminal.Gui.TextField.ProcessKey(Terminal.Gui.KeyEvent kb) Line 565	C#
 	Terminal.Gui.dll!Terminal.Gui.View.ProcessHotKey(Terminal.Gui.KeyEvent keyEvent) Line 1881	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.ProcessKeyEvent(Terminal.Gui.KeyEvent ke) Line 431	C#
 	Terminal.Gui.dll!Terminal.Gui.WindowsDriver.ProcessInput(Terminal.Gui.WindowsConsole.InputRecord inputEvent) Line 859	C#
 	Terminal.Gui.dll!Terminal.Gui.WindowsDriver.PrepareToRun.AnonymousMethod__34_0(Terminal.Gui.WindowsConsole.InputRecord e) Line 759	C#
 	Terminal.Gui.dll!Terminal.Gui.WindowsMainLoop.Terminal.Gui.IMainLoopDriver.MainIteration() Line 1881	C#
 	Terminal.Gui.dll!Terminal.Gui.MainLoop.MainIteration() Line 295	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.RunMainLoopIteration(ref Terminal.Gui.Application.RunState state, bool wait, ref bool firstIteration) Line 1014	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.RunLoop(Terminal.Gui.Application.RunState state, bool wait) Line 996	C#
 	Terminal.Gui.dll!Terminal.Gui.Application.Run(Terminal.Gui.Toplevel view, System.Func<System.Exception, bool> errorHandler) Line 1172	C#
 	UICatalog.dll!UICatalog.Scenario.Run() Line 200	C#
 	UICatalog.dll!UICatalog.UICatalogApp.Main(string[] args) Line 111	C#

[tznind]

Thanks for the screenshot wVirtualKeyCode is 231 in the image. The ConsoleKey Enum value for that is ‘Packet’:

Packet | 231 | The PACKET key (used to pass Unicode characters with keystrokes).

_https://docs.microsoft.com/en-us/dotnet/api/system.consolekey?view=net-6.0_

Not sure if that means anything but tomorrow I can try hacking my codebase to force every keystroke to those values and then step through the debugger to see if its being misinterpreted.

VK_PACKET 0xE7 Used to pass Unicode characters as if they were keystrokes. The VK_PACKET key is the low word of a 32-bit Virtual Key value used for non-keyboard input methods. For more information, see Remark in KEYBDINPUT, SendInput, WM_KEYDOWN, and WM_KEYUP

[BDisp]

Well I believe there some way to handle that PACKET key so the right keystroke is filtered. I’m curious 😃