Hi friends,
Just to throw out an alternate API approach (which I would not go anywhere
near close to saying is a better approach), we could consider a three-value
enum getter API:
public static KeyLockState Platform::getKeyLockState(KeyCode keyCode);
Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT }
I'll be the first to argue against yet another enum, but I wanted to throw
this out there as an alternate approach that avoids the needs for checked
exceptions (which is what I assume is meant by 'throw an exception', as
opposed to throwing a runtime exception).
-- Jonathan
On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:
> For JavaFX 17, I am planning to add a minor enhancement to read the
> state of the keyboard lock keys, specifically, Caps-Lock, Num-Lock, and
> maybe Scroll-Lock (although I might defer the latter to a future version
> since it will be more difficult to test, and doesn't seem as useful).
>
> This is currently tracked by JDK-8259680 [1].
>
> The proposed API would be something like:
>
> public static boolean Platform::isKeyLocked(KeyCode keyCode);
>
> One question is whether we should throw an exception if the key state
> cannot be read on a particular system (e.g., Num Lock on macOS), which
> is what the similar AWT API does. I don't have a strong opinion on that
> poont, although I wouldn't want to throw an exception if the keyboard
> doesn't have the key in question, as long the system is able to read the
> state accurately.
>
> Comments are welcome.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8259680
>
>
