-
Notifications
You must be signed in to change notification settings - Fork 689
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
Shift+key denied by text field as "control character" on remote systems #2008
Comments
Very strange. Does it make any difference if you launch with Also what does your $TERM environment variable say ( Also just to rule it out, I take it scroll lock or function lock are also off? Looking at that Key value in your first screen shot it definitely looks like there is another flag bit set:
Can you please reproduce the first screenshot without numlock and we can see what the value of |
Yes. Definitely looks like Thanks for sticking with this and sharing those screenshots its very helpful! |
I already test with all the related terminals and I didn't get the issue with the |
Ok so I have a hacky workaround which is to strip the Shift bit from the Application.RootKeyEvent = (k) => {
// strip shift mask from key code
k.Key = (Key)(k.KeyValue & (uint)0x0fffffff);
return false;
}; But I would still like to get to the bottom of this. The entry point for key handling is
If you could put a conditional break point in there (e.g. see below). We should be able to see if that extra bit is being fed in by windows or is being introduced by Terminal.Gui. Note that you may need to add the shift mask to that conditional expression if it isn't hit in your environment. I think what is supposed to happen is that |
Will do as soon as I'm back on my Linux machine! When I'm RDPing from Windows it apparently... works. Not sure what to make of that. Is Remmina doing shenanigans there? We'll see. |
In |
@tznind Here is a screenshot at the position you asked for: Call stack:
Screenshot of the app after continuing: And I'm stupid. With my last test I still had the -usc parameter version selected in Visual Studio, so the error might still be there with the Windows to Windows RDP connection. Will check again, when I'm back at the Windows machine... fyi @BDisp |
Thanks for the screenshot
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.
|
Seems to be connected to remote connecting to systems. Did a Google. Here is somebody experiencing this as well with AnyDesk: https://stackoverflow.com/q/73076917 The dates seem recent. Might be something new? |
Well I believe there some way to handle that PACKET key so the right keystroke is filtered. I'm curious :-) |
Fixes #2008 - 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:
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):
Additional context
Call stack:
The text was updated successfully, but these errors were encountered: