P4
Test case attached. When using these cells (I have same problem with ChoiceBox) there is no way to trap the focus lost and cancel/commit the edit.
- Click on a cell.
- Click on the button to loose the focus.
- Observe that the edited cell is no more the one that was edited.
In the testcase I am modifying the table content on focus lost, the table becomes inconsistent. Should the table protect itself against such an inconsistent state?
As a workaround I tried to develop my own TextFieldCell cell but to have a properly behaving cell you need to duplicate CellUtils and TextFieldTableCell code, so I have duplicated a bunch of code to plug a simple focus listener.
These cells should expose the embedded piece of UI for customisation.
- Click on a cell.
- Click on the button to loose the focus.
- Observe that the edited cell is no more the one that was edited.
In the testcase I am modifying the table content on focus lost, the table becomes inconsistent. Should the table protect itself against such an inconsistent state?
As a workaround I tried to develop my own TextFieldCell cell but to have a properly behaving cell you need to duplicate CellUtils and TextFieldTableCell code, so I have duplicated a bunch of code to plug a simple focus listener.
These cells should expose the embedded piece of UI for customisation.
- relates to
-
JDK-8089514 [TableView, TreeView, ListView, TreeTableView] Clicking outside of the edited cell, node, or entry should commit the value
-
- Open
-
-
JDK-8187307 ListView, TableView, TreeView: receives editCancel event when edit is committed
-
- Resolved
-