On Fri, 15 May 2026 21:24:36 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. >> - Those two 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, or the user >> scrolled until the cell is reused >> - Default will call `cancelEdit()` >> - to be backward compatible >> - because we do not know what value we should commit, even if we want to >> (subclasses will know that better) >> - `TextFieldXXXCell`s will utilize and call `stopEdit()`, and they know >> exactly the value they can commit >> >> 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 or the focus is lost >> - Developers that subclassed `TextFieldXXXCell`s to implement their own >> commit-on-focus-lost/editing operation stopped may need to remove their >> custom logic. Since all `Cell` operations that change the editing state will >> check the editing state (`isEditing(9`) before, their might be no problem at >> all. >> - Developers can check out the source of `TextFieldXXXCell`s if they wish to >> adapt the pattern to their own cell implementations >> >> --- >> >> <details> >> <summary>More about the API, Considerations and Follow Ups</summary> >> >> API >> - >> - Instead of calling `cancelEdit`, every cell now calls `stopEdit` 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 `commitEdit` instead >> - There are multiple 'events' that can lead to a editing change. Every >> change will now call `stopEdit`. >> 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. Therefo... > > Marius Hanl has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains 10 additional > commits since the last revision: > > - 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 > - Fix problem when initially selecting a cell > - Simplify focus listener > - Merge branch 'master' of https://github.com/openjdk/jfx into > focus-edit-stop > - focus edit Seems like https://github.com/openjdk/jfx/pull/2124 was already worth it - it did uncover that `testJDK8119995` actually created a new temporary stage before although we did not expect it (Which was of course not visible to me when writing the test). Therefore, the test could not really test what it was supposed to. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-4464189955
