[Rev 01] RFR: 8193800: TreeTableView selection changes on sorting
fastegal at openjdk.java.net
Wed Jun 3 13:01:44 UTC 2020
On Wed, 3 Jun 2020 12:03:43 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:
>>> The algorithm looks correct to me for sorting. How much regression testing have you done for cases where rows or
>>> columns are inserted?
>> I have tested with a small TreeTableView of 15 rows of 3 levels and 3 columns.
>> Would it be enough to test with TreeTableView of ~500 rows of 5 levels, 10 columns ?
>> Update: I am testing with 7 level of nested rows, with 10, 9, 7, 6, 5, 4, 3 number of children in each level
>> respectively. The fix works fine till level 3. But can observe issue with level 4 and further. Shall debug this more
>> and update.
> hmm .. TreeModificationEvent seems to have a different interpretation (than a list change) of _permutated_: its
> wasPermutated may return true even on a replace - that's probably why some tests are throwing a IllegalStateException
> before the fix. The other way round: do we really want to introduce a singularity in selection handling after
> replace? The other selectionModels for virtualized controls try to keep the selectedItem/Index only.
need a break ;)
Will come back later with an example comparing the behavior of multiple selection state across virtualized controls -
- ListView/TableView keep selection (corrrectly) on all selectedItems, adjust indices as needed
- TreeView: ??
- TreeTableView: throws IllegalState before this fix, keeps selection (correctly) on all selectedItems, adjusts indices
as needed after this fix
Replace with same items in different sequence
- ListView/TableView: keep only selectedItem, adjust selectedIndex as needed
- TreeView: keeps selectedIndices (?)
- TreeTableView: throws IllegalState before this fix, keeps selectedItems, adjusts selectedIndices as needed after this
More information about the openjfx-dev