Community
Participate
Working Groups
(RC3) I re-sort a VIRTUAL TableViewer's contents by calling setSortOrder() on its DeferredContentProvider. Afterwards, the TableViewer's selection index is the same as before, even though the previously selected row's index has changed due to re-sorting. The user's expectation will be that after clicking on a column header for re-sorting, the previously selected row (object) will still be selected. This behaviour differs from a normal TableViewer that is provided with a re-sorted input: it will update the selection to reflect the new position of the previously selected row (by means of preservingSelection()).
Tod: this is another symptom of the problem we discussed earlier. The table viewer needs to know about the complete set of known elements in order to maintain the selection when rows are repositioned, but the content provider doen't have any way to make the information available. The same thing occurs when rows are inserted or removed from a table with an active selection.
Hitesh is now responsible for watching bugs in the [Viewers] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
