On Mon, 13 Oct 2025 12:19:52 GMT, Marius Hanl <[email protected]> wrote:
> This is an initial poc 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 `TextFiield` cells, but we may split > this later on). > > 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. We do not really know what intention led to e.g. a > change of the editing index. > - Every `MOUSE_PRESSED` shifts the focus to the cell container, which is > undesired in case of editing the cell. So this event is now consumed. > - All `TextField` cells now commit their value (instead of cancel) on focus > loss > - `TextField` Escape handling was badly implemented (it was never really > called, as the cell container handled Escape before) > > Considerations > - > - I tried to make the API minimal, and without breaking changes (other than > the `TextField` cells committing their values, but we may split this up) > - 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 `focusWithin` property instead for all 4 Cell > Containers and not calling `requestFocus` for nearly every `MOUSE_PRESSED` > event. If we decide so, this is needs to be done before merging this PR. > - Clicking the `ScrollBar` 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 (`focusWithin`) > - It might be hard for a developer to exactly know the cause why `stopEdit` > is called. This does not seem like a problem, as e.g. for a `TextField`, you > normally register listeners for e.g. pressing the Escape key on it, so you > keep full control. > > Another Approach > - > - Another Approach I tested could be to request the focus to a cell when > clicked/edited, to ensure that the focus listener i... I think this needs more discussion before it is ready for formal review. Perhaps it should be moved to Draft until the discussion converges on an approach? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1935#issuecomment-3403306288
