mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-18 11:38:05 -05:00
dfc215d0c0
TranslateKey() on Windows passed all numeric-keypad key events to this function in terminal.c, and accepted whatever it gave back. That included the handling for the trivial case of the numeric keypad, when Num Lock is on and application keypad mode hasn't overridden it, so that the keypad should be returning actual digits. In that case, format_numeric_keypad_key() itself was returning the same ASCII character I had passed in to it as a keypad identifier, and TranslateKey was returning that in turn as the final translation. Unfortunately, that means that with Num Lock on, the numeric keypad translates into what _I_ used as the logical keypad codes inside the source code, not what the local keyboard layout thinks are the right codes. In particular, the key I identified as keypad '.' would render as '.' even on a German keyboard where it ought to produce ','. Fixed by removing the fallback case in format_numeric_keypad_key() itself, so now it returns the empty string if it didn't produce an escape sequence as its translation. Instead, the special case is in window.c, which checks for a zero-length output string and handles it by falling through to the keyboard-layout specific ToUnicode code further down TranslateKey(). On the GTK side, no change is needed here: the GTK keyboard handler does things in the opposite order, by trying the local input method _first_ (unless it can see a reason up front to override it), and only calling format_numeric_keypad_key() if that didn't provide a translation. So the fallback ASCII translation in the latter was already not used.