Navigation KeyEvents consumed when there is nothing to navigate, bug?

[John Hendrikx]

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.hendrikx at 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.