> When processing a `WM_CHAR` event on an OEM key (punctuation, symbol, dead > key) the glass code will dynamically query the key's unshifted character to > determine the Java code to assign to it. This is necessary since the > relationship between OEM key codes and the characters they generate varies > from layout to layout. > > The Robot implementation was consulting a table which assumed a fixed > relationship between Java codes and Windows key codes even for the OEM keys. > The table was also missing entries for any Java code not on a US QWERTY > layout, like PLUS. > > In this PR if we don't find the Java code in the table or if it maps to an > OEM key (which may be wrong) we sweep through all the OEM keys looking for > the matching Java code.
Martin Fox has updated the pull request incrementally with one additional commit since the last revision: A Robot now correctly handles KeyCodes that aren't in the current layout ------------- Changes: - all: https://git.openjdk.java.net/jfx/pull/702/files - new: https://git.openjdk.java.net/jfx/pull/702/files/dcd4c98c..e9dfaa75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=702&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=702&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/702.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/702/head:pull/702 PR: https://git.openjdk.java.net/jfx/pull/702
