-
Bug
-
Resolution: Fixed
-
P3
-
jfx19
-
b11
-
generic
-
generic
Since JDK-8251480 and JDK-8285197, we use a (Tree)TableRow for measuring the preferred column size.
Both don't initialize the (Tree)TableView, leading to a NPE if the table view is accessed inside the (Tree)TableRowSkin.
private static class CustomTableRowSkin<T> extends TableRowSkin<T> {
public CustomTableRowSkin(TableRow<T> tableRow) {
super(tableRow);
tableRow.getTableView().getFixedCellSize(); // THROWS NPE
}
}
Fix is to initialize the `(Tree)TableView` when creating the measure row for autosizing.
This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise).
With the above mentioned change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). Ticket which described that behaviour as well: https://bugs.openjdk.org/browse/JDK-8274065
Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events.
Both don't initialize the (Tree)TableView, leading to a NPE if the table view is accessed inside the (Tree)TableRowSkin.
private static class CustomTableRowSkin<T> extends TableRowSkin<T> {
public CustomTableRowSkin(TableRow<T> tableRow) {
super(tableRow);
tableRow.getTableView().getFixedCellSize(); // THROWS NPE
}
}
Fix is to initialize the `(Tree)TableView` when creating the measure row for autosizing.
This will guarantee, that we can access the `(Tree)TableView` in the `(Tree)TableRowSkin`, which is currently only null during the autosizing (It is always set otherwise).
With the above mentioned change, a NPE is happening as the `(Tree)TableRow` currently assumes, that there must be a `VirtualFlow` somewhere in the scene (parent). Ticket which described that behaviour as well: https://bugs.openjdk.org/browse/JDK-8274065
Finally, the `(Tree)TableRow` must be removed after the autosizing and the index must be set to `-1` (as for the cell) so that e.g. `cancelEdit()` is not triggered. Some tests catched that (see `test_rt_31015`). This did not happen before as the table row setup was not complete, but now the row does know the table and therefore installs some listener on it in order to fire corresponding edit events.
- relates to
-
JDK-8289751 Multiple unit test failures after JDK-8251483
- Resolved
-
JDK-8251483 TableCell: NPE on modifying item's list
- Resolved
-
JDK-8292009 Wrong text artifacts in table header
- Resolved