On Tue, 17 Oct 2023 20:21:30 GMT, Martin Fox <m...@openjdk.org> wrote:
> After finding the Window virtual key code for a character getKeyCodeForChar > was using a mapping table that only works correctly for U.S. English to > retrieve the Java key code. This caused getKeyCodeForChar to encode keys > differently than the original key event handling machinery. > > With this fix the Robot, getKeyCodeForChar, and the code that handles > platform key events all agree on how Windows VK codes should map to Java > codes. > > The manual KeyboardTest app can be used to test this (tests/manual/events). > Run the tests by selecting "without keypad combinations" in the second > dropdown. This will use a Robot to test KeyCharacterCombinations excluding > the numeric keypad (which is a separate issue). Looks good! I've tested this PR on Windows 11 with my Spanish keyboard. Without the patch from this PR, the KeyboardTest app (without keypad combinations) gives: [Win] Testing 80 keys on Spanish without keypad combinations Failed: code Delete did not match combination U+007F Failed: code Quote did not match combination ' Failed: code Quote did not match combination ? Failed: code Inverted Exclamation Mark did not match combination ¡ Failed: code Inverted Exclamation Mark did not match combination ¿ Failed: code Plus did not match combination + Failed: code Plus did not match combination * Failed: code Plus did not match combination ] Tested 80 keys with 8 failures with the patch: [Win] Testing 80 keys on Spanish without keypad combinations Tested 80 keys with 0 failures The same goes with US English, German and French (after setting those as local keyboards). ------------- Marked as reviewed by jpereda (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1264#pullrequestreview-1730839151
