Replies: 1 comment
-
This defect makes it impossible to write a robust console application in Windows with customizable key-bindings. And a backwards-compatible solution seems to be quite simple:
The bit (I discuss this defect in detail in my list of defects of keyboard input on Windows.) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
[Given a dearth of documentation on robust handling of user character input on Windows, I do not know whether this is a feature request, or not. So I post it here.]
As far as I understand, there is no way for a console application to process a mix of input of “accelerators” keypresses (such as Ctrl-Shift-= etc) and of Unicode characters. The major stumbling block is the recognition of dead keys: the application cannot tell a dead key from an “accelerator”.
(Using the undocumented flag of
ToUnicodeEx()
, one could do it if one knew the current “input locale” — but I see no way to find the input locale due to the console wrapper running with very high elevation…)Question 1: is the analysis above valid? Or maybe there is some clever trick to circumvent this?
Question 2: is there going to be changes in this regard, so that applications can recognize dead keys
Question 3: A way to see changes of the “input locale” would be also beneficial!
Beta Was this translation helpful? Give feedback.
All reactions