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 sorry, please reopen this PR. @lukostyra could you be the second reviewer once it's been reopened? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-5329525846
