On Wed, 3 Jun 2020 12:03:43 GMT, Jeanette Winzenburg <faste...@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 - preliminary results Sort: - 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 fix ------------- PR: https://git.openjdk.java.net/jfx/pull/244
