On Tue, 2 Jun 2020 18:02:50 GMT, Ambarish Rapte <[email protected]> wrote:
>> Issue:
>> In TreeTableView, in case of Multiple selection mode, if nested items are
>> selected, then TreeTableView does not
>> retain/update the selection correctly when the tree items are
>> permuted(either by `sort()` or by reordering using
>> `setAll()`). Cause:
>>
>> 1. For permutation, the current implementation uses `TreeModificationEvent`
>> to update the selection.
>> 2. The indices from these TreeModificationEvents are not reliable.
>> 3. It uses the non public `TreeTablePosition` constructor to create
>> intermediate `TreeItem` positions, this constructor
>> results in another unexpected TreeModificationEvent while one for sorting is
>> already being processed. 4. In case of
>> sorting, there can be multiple intermediate TreeModificationEvents
>> generated, and for each TreeModificationEvent, the
>> selection gets updated and results in selection change events being
>> generated. 5. Each time a TreeItem is expanded or
>> collapsed, the selection must be shifted, but shifting is not necessary in
>> case of permutation. All these issues
>> combine in wrong update of the selection. Fix:
>>
>> 1. On each TreeModificationEvent for permutation, for updating the
>> selection, use index of TreeItem from the
>> TreeTableView but not from the TreeModificationEvent. 2. Added a new non
>> public TreeTablePosition constructor, which is
>> almost a copy constructor but accepts a different row. 3. In case of
>> sorting, send out the set of selection change
>> events only once after the sorting is over. 4. In case of setAll, send out
>> the set of selection change events same as
>> before.(setAll results in only one TreeModificationEvent, which effectively
>> results in only one set of selection change
>> events). `shiftSelection()` should not be called in case of permutation i.e.
>> call `if (shift != 0)`
>> Verification:
>> The change is very limited to updating of selection of TreeTableView items
>> when the TreeItems are permuted, so the
>> change should not cause any other failures. Added unit tests which fail
>> before and pass after the fix.
>
> Ambarish Rapte has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Change isSortingInProgress to package scope
The algorithm looks correct to me for sorting. How much regression testing have
you done for cases where rows or
columns are inserted?
I left a few comments, and will complete my testing in parallel.
modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java
line 1822:
> 1821: public void sort() {
> 1822: sortingInProgress = true;
> 1823: final ObservableList<TreeTableColumn<S,?>> sortOrder =
> getSortOrder();
I presume that sorting cannot be called recursively?
modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableView.java
line 1807:
> 1806:
> 1807: boolean sortingInProgress;
> 1808: boolean isSortingInProgress() {
Minor: the field itself can be private.
modules/javafx.controls/src/main/java/javafx/scene/control/TreeTablePosition.java
line 82:
> 81: // This causes issue by triggering a new TreeModificationEvent while
> one TreeModificationEvent
> 82: // is being handled currently.
> 83: // This is kind of a copy constructor with different value for row.
The first three lines of added comments don't really belong here. I would just
document the new constructor as a
copy-like constructor (with a different row) and mention that it is used by the
TreeTableView::sort method.
-------------
PR: https://git.openjdk.java.net/jfx/pull/244
