<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Marius,</p>
<p>This may be unrelated, but it may be problematic to rely on
committing values using focus lost:<br>
</p>
<p>I've built a lot of code that relies on focus lost to "commit"
values to some underlying model. However, I noticed that a focus
lost handler for committing values is insufficient when an action
is triggered that doesn't trigger a loss of focus. For example,
if I have a field "email address" and a Button "Send Email", and I
have a focus lost handler to commit the email address textfield to
an underlying model, then pressing the Button will not trigger
that handler and the underlying model may not have been updated
with the latest edits.</p>
<p>Solutions to trigger the correct action are all a bit tricky or
annoying:</p>
<p>- Query all fields for their current contents as focus lost is
not entirely reliable for this purpose<br>
- Have fields update models immediately (which would be on every
key press...) -- this is not very efficient, and can get in the
way of validation / model restrictions<br>
- Have controls listen to a "COMMIT" event (this is fired at the
current focus owner by the Button). This event may be veto'd if
committing the value resulted in a validation error, in which case
the button press is cancelled</p>
<p>I don't like any of these, but using the last option at the
moment because I like constant updates and having to requery UI
components even less...</p>
<p>--John<br>
</p>
<p><br>
I noticed however that if you edit some field (it doesn't have to
be in a table view, just a regular field), and have a focus lost
handler that commits the value, that this focus lost handler is
insufficient...<br>
</p>
<div class="moz-cite-prefix">On 13/10/2025 14:53, <a class="moz-txt-link-abbreviated" href="mailto:mariushanl@web.de">mariushanl@web.de</a>
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:trinity-2d5ed291-7153-4304-a0df-c7eca7df1ff3-1760360034938@trinity-msg-rest-webde-webde-live-df5b95767-tqstd">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">All,</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">I created an initial poc 1*
to support developers to commit the cell value when the focus
is lost 2* (including 3*).</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">More specifically, this
gives the maximum flexibility to choose what should happen
when the focus is lost or the editing index changed (which may
happen when clicking into another cell while editing).</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;">All
information mentioned here are also in the description of the
PR.</div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"> </div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><strong>API</strong></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><strong> </strong></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">- Instead of calling `<em>cancelEdit</em>`,
every cell now calls `<em>stopEdit</em>` when the focus is
lost or the editing index changed. The default behavior is
cancelling the edit, but developers can now override the
behavior and allow a `<em>commitEdit</em>` instead<br>
- There are multiple 'events' that can lead to a editing
change. Every change will now call `<em>stopEdit</em>`.<br>
It is therefore the responsibility of the developer to decide,
when it makes sense to actually commit the value instead of
cancelling it. This decision was made as the behavior is
manipulating the editing index, but you as a developer can as
well. We do not really know what intention led to e.g. a
change of the editing index.<br>
- Every `<em>MOUSE_PRESSED</em>` shifts the focus to the cell
container, which is undesired in case of editing the cell. So
this event is now consumed.<br>
- All `<em>TextField</em>` cells now commit their value
(instead of cancel) on focus loss<br>
- `<em>TextField</em>` Escape handling was badly implemented
(it was never really called, as the cell container handled
Escape before)</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"><strong>Considerations</strong><br>
<br>
- I tried to make the API minimal, and without breaking
changes (other than the `<em>TextField</em>` cells committing
their values, but we may split this up)<br>
- The Cell Container focus behavior is, well, weird right now.
That is why consuming the event is needed to better support
this PR. One thing we may can consider is using the `<em>focusWithin</em>`
property instead for all 4 Cell Containers and not calling `<em>requestFocus</em>`
for nearly every `<em>MOUSE_PRESSED</em>` event. If we decide
so, this is needs to be done before merging this PR.<br>
- Clicking the `<em>ScrollBar</em>` now commits/cancels the
edit. I checked other applications and this is very common.
But something I need to note here. This probably can be fixed
in the same way mentioned above (`<em>focusWithin</em>`)</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">- It might be hard for a
developer to exactly know the cause why `<em>stopEdit</em>` is
called. This does not seem like a problem, as e.g. for a `<em>TextField</em>`,
you normally register listeners for e.g. pressing the Escape
key on it, so you keep full control.</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"><strong>Another Approach</strong><br>
<br>
- Another Approach I tested could be to request the focus to a
cell when clicked/edited, to ensure that the focus listener is
ALWAYS called before another cell will reach the editing
state. Again, we probably need to change the focus handling to
e.g. use the `<em>focusWithin</em>` property. With this
approach, we can only call `<em>stopEdit` </em>when the focus
changed (since it is now called always), but not when the
editing index changed.<br>
</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">1* - <a
href="https://github.com/openjdk/jfx/pull/1935"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jfx/pull/1935</a></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">2* - <a
href="https://bugs.openjdk.org/browse/JDK-8089514"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8089514</a></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">3* - <a
href="https://bugs.openjdk.org/browse/JDK-8089311"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8089311</a></span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span
style="background-color: #ffffff;">-- Marius</span></div>
</blockquote>
</body>
</html>