I'm talking about the FX versions of these events:
/**
* This event occurs when a key has been pressed.
*/
public static final EventType<KeyEvent> KEY_PRESSED =
new EventType<KeyEvent>(KeyEvent.ANY, "KEY_PRESSED");
/**
* This event occurs when a key has been released.
*/
public static final EventType<KeyEvent> KEY_RELEASED =
new EventType<KeyEvent>(KeyEvent.ANY, "KEY_RELEASED");
/**
* This event occurs when a character-generating key was typed
* (pressed and released). The event contains the {@code character}
* field containing the typed string, the {@code code} and {@code text}
* fields are not used.
*/
public static final EventType<KeyEvent> KEY_TYPED =
new EventType<KeyEvent>(KeyEvent.ANY, "KEY_TYPED");
For navigation keys, KEY_PRESSED is swallowed whether it can be used or
not. KEY_TYPED comes through (but not for cursor keys as they have no
character, but tab does). KEY_RELEASED also happens (but only after the
key is released, key repeat generated more KEY_PRESSED events which are
all swallowed).
--John
On 22/05/2023 23:09, Michael Strauß wrote:
The only key events in WinUI are KeyDown and KeyUp (both are defined
on the UIElement class).
Tab keys are not consumed for both KeyDown and KeyUp (i.e. a parent
element receives the events with regular KeyDown/Up handlers), while
action keys are always consumed.
On Mon, May 22, 2023 at 10:05 PM John Hendrikx <john.hendr...@gmail.com> wrote:
You mean KEY_TYPED or KEY_PRESSED ? In my experience, it consumes only
the PRESSED events while TYPED and RELEASED are left alone.
On 22/05/2023 20:37, Michael Strauß wrote:
Just to add a data point:
I've tried to recreate this scenario in a WinUI 3 application. A
single button, and nowhere to shift focus.
While the button does consume action keys (space and enter), it does
not consume the tab key.
Interestingly, it also doesn't consume the tab key when the focus
_can_ be moved to a different control.
