Hello! On 15/05/2024 14:49, Martin Fox wrote: > Mark, > > You may already know this but before JavaFX 21 the Mac and Windows Robot code > had some long-standing bugs with non-US keyboards. Linux is in better shape > but you can encounter problems if the user has installed multiple layouts (I > have a PR pending to fix that). That might explain some of the flakey > behavior you’ve been seeing. Your approach might also invoke an unexpected > dead key depending on what modifiers you’re probing.
Very possible. I use this base set of keycodes: https://github.com/io7m-com/xoanon/blob/ac7c9c900c7908c5760a74d6cf4056fe3ffb8e92/com.io7m.xoanon.commander/src/main/java/com/io7m/xoanon/commander/internal/XCCommander.java#L235 I iterate over each key in that set, sending that keycode to a text field. I then do the same for each keycode but with the shift key held. I don't doubt that it could cause havoc in some setups! > With one exception JavaFX doesn’t have any facility for querying the keyboard > layout. It relies on the platform code to take in keyboard events and > translate them to JavaFX events on the fly. The exception is the internal > call Toolkit.getKeyCodeForChar which attempts to map from a character to a > KeyCode and is used to match shortcuts specified as KeyCharacterCombinations. > Unfortunately the current implementation on Mac and Linux can’t really be > extended to cover the sort of testing you’re trying to do. Right. > JavaFX needs a better framework for testing text entry and I’ve thought about > how that might look... In my case, I'm almost always testing whether some UI elements become enabled or disabled based on validation occurring on a text field of some kind. A recent case was checking to see if a text field correctly rejected input that didn't appear to be an email address. Typing '@' into the field was difficult to make reliable. :) -- Mark Raynsford | https://www.io7m.com
