On Fri, 19 Jun 2026 07:25:44 GMT, Marius Hanl <[email protected]> wrote:
>> This is an implementation for the long standing issue of allowing to commit >> a cell value when the focus is lost or the editing index (cell) changed. >> This also contains >> [JDK-8089311](https://bugs.openjdk.org/browse/JDK-8089311) (for better >> understanding the usecase with `TextField` cells, but we may split this >> later on). >> >> TLDR >> - >> - New method `stopEdit()` >> - Called when the editing operation was stopped OR the focus is lost. >> - Both are situations where we can not guess what should happen. We do >> know though that cancelling the edit without further customization is wrong. >> Instead, developers can now decide what to do >> - Examples: >> - Editing operation can be stopped by the cell container, because the >> developer called `edit()` with another index >> - The user scrolled until the cell is reused >> - Focus is lost because the user clicks on another focusable Node >> - The default implementation will call `cancelEdit()` >> - To be backwards compatible >> - Because we do not know what value we should commit. A `Cell` does not >> know what it means to be in the edit state. However, subclasses will know >> that better. A `TextFieldTableCell` knows the value of the `TextField` and >> can directly commit (or convert before) the text entered from the User. >> - The existing `TextFieldXXXCell`s will utilize and call `stopEdit()`, and >> they know exactly the value they can commit (the text) >> >> Behavioral Change >> - >> - Developers can override `stopEdit()` and call `commitEdit()` with the >> desired value >> - All `TextFieldXXXCell`s will now commit their value when the editing >> operation was stopped >> - They still cancel their edit when Escape is pressed >> - Developers that subclassed `TextFieldXXXCell`s to implement their own >> commit-on-focus-lost handling may need to remove their custom logic >> - As outlined in the comments, this is probably a very rare case because >> you can not access the `TextField` when subclassing it >> - But if developers did indeed subclass it: All `Cell` operations, that >> change the editing state, will check `isEditing()` before. So there might be >> no problem at all and they will continue working, However, it is recommended >> to adapt to the new `stopEdit` flow >> - Developers can check out the `TextFieldXXXCell`s if they wish to adapt the >> pattern to their own cell implementations >> >> - From my personal experience, in every project I saw a custom >> implementation of a `TextFieldTableCell` (Note: Not using or subclassing >> the ... > > Marius Hanl has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into > focus-edit-stop > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java > - Merge branch 'master' of https://github.com/openjdk/jfx into > focus-edit-stop > - fix tests the real way + doc > - review comments and test fix > - Merge branch 'master' of https://github.com/openjdk/jfx into > focus-edit-stop > - javadoc > - Improve behavior select signature, improve javadoc > - make it final, improve docs > - Merge branch 'master' of https://github.com/openjdk/jfx into > focus-edit-stop > - change the way focus is shifted > - ... and 4 more: https://git.openjdk.org/jfx/compare/8020a859...0d33a8b8 modules/javafx.controls/src/main/java/javafx/scene/control/Cell.java line 359: > 357: * would have focused set to true. > 358: */ > 359: focusedProperty().addListener(_ -> { I realize this is old behavior but using the focused property is questionable. The focused property will be set to false if the user activates a different window. In most toolkits clicking on a different window would not commit text entry. The text should just sit there waiting for the user to re-activate the original window. The more correct way of doing this is to observe the scene's focusOwner since that doesn't change when the window loses focus. But it's possible you're picking up other behavior by monitoring the focused property that's important, I know the controls mess with it in various ways. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1935#discussion_r3807634143
