mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
Remove ASCII fallback in format_numeric_keypad_key().
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.
This commit is contained in:
parent
ce780c9b33
commit
dfc215d0c0
@ -6836,12 +6836,6 @@ int format_numeric_keypad_key(char *buf, Terminal *term, char key,
|
||||
}
|
||||
}
|
||||
|
||||
if (p == buf && !app_keypad && key != 'G') {
|
||||
/* Fallback: numeric keypad keys decode as their ASCII
|
||||
* representation. */
|
||||
p += sprintf(p, "%c", key);
|
||||
}
|
||||
|
||||
return p - buf;
|
||||
}
|
||||
|
||||
|
@ -4515,10 +4515,26 @@ static int TranslateKey(UINT message, WPARAM wParam, LPARAM lParam,
|
||||
break;
|
||||
}
|
||||
|
||||
p += format_numeric_keypad_key(
|
||||
(char *)p, term, keypad_key,
|
||||
shift_state & 1, shift_state & 2);
|
||||
return p - output;
|
||||
{
|
||||
int nchars = format_numeric_keypad_key(
|
||||
(char *)p, term, keypad_key,
|
||||
shift_state & 1, shift_state & 2);
|
||||
if (!nchars) {
|
||||
/* If we didn't get an escape sequence out of the
|
||||
* numeric keypad key, then that must be because
|
||||
* we're in Num Lock mode without application
|
||||
* keypad enabled. In that situation we leave this
|
||||
* keypress to the ToUnicode/ToAsciiEx handler
|
||||
* below, which will translate it according to the
|
||||
* appropriate keypad layout (e.g. so that what a
|
||||
* Brit thinks of as keypad '.' can become ',' in
|
||||
* the German layout). */
|
||||
break;
|
||||
}
|
||||
|
||||
p += nchars;
|
||||
return p - output;
|
||||
}
|
||||
|
||||
int fkey_number;
|
||||
case VK_F1: fkey_number = 1; goto numbered_function_key;
|
||||
|
Loading…
Reference in New Issue
Block a user