[External] : Re: Focus delegation API

[Martin Fox]

> On Aug 6, 2025, at 3:54 PM, John Hendrikx <john.hendrikx at gmail.com> wrote:
> 
> 
> On 06/08/2025 18:06, Martin Fox wrote:
>> 
>> The TextField of a ComboBox or Spinner is not just an artifact of its skin. They are both explicitly composite controls that contains a TextField inside. It’s part of the API. And if you were to install some filters on the Scene to track Key and InputMethod events you could easily conclude that that TextField is the focus owner (it walks like the focus owner, it quacks like the focus owner).
> 
> I disagree.  A ComboBox and Spinner are primitives.  Their
> implementation via replacable Skins may or may not use a TextField,
> that's completely up to the Skin.

As I mentioned in my earlier e-mail (in the paragraph you quoted) the TextField is part of the ComboBox and Spinner API. Accessing it is the only way to, say, attach a TextFormatter to a Spinner. Consult the docs starting at version 2.2.

The proposal (lifted from WPF) is to provide a mechanism which would allow a Control to replace an event’s original target with itself. This is a low-cost way of making the control appear to be a black box at the event level. It would certainly have a lower cost than, say, trying to hide skin nodes from the rest of the scene graph. I’m not aware of any toolkit that even attempts that.

> - Skins re-use listener and event handler endpoints on the Control,
> leaving users baffled by events sometimes being consumed before they see
> them (if they added their handler late) or after they see them (if they
> were the first to add their handler, or if the Skin was replaced causing
> a re-ordering -- something very interesting to deal with); for listeners
> this is relatively safe, as they don't have a consumption mechanism, but
> not for events --  another mistake; skin event handlers should have been
> part of a separate list so there can never be any intermixing of user
> and skin event handlers

This is a known pain point for developers that can be fixed without re-writing the underpinnings of JavaFX (in other words, with a reasonable cost/benefit ratio). I’m not sure why it hasn’t been done already.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250807/67d161d4/attachment.htm>