I have a TableViewer (and associated model-class) which works fine,
model-sorting, model-filtering, GUI-selection, etc. (I am using
setUseHashlookup(true).)
Note: I am doing all filtering and sorting in the model-class. The
model-elements have an equals() method defined, that as far as I can
tell works correctly.
I then virtualize my TableViewer, according to the JFace snippets, using
ILazyContentProvider -- and now it runs much faster (hurrah!).
However -- the programmatic setting and getting of selections is now
almost always incorrect. If I get the selection just before refreshing
the viewer, and then reset the selection just afterwards, the indicated
element is *never* selected. (Plus, the retrieved selection is itself
often incorrect, i.e., different from what the selection was before the
sort or filter.)
The problem occurs even when I filter the model and expand the window
enough that *all* elements are always displayed (i.e., they have all
been fetched).
Furthermore if I add to the (virtualized) TableViewer an
ISelectionChangedListener which does nothing but print the selection, I
see that my programmatic change of selection is being registered, as are
all the GUI-events (click to select).
Moreover, the problem occurs even when I use that selection-changed
listener to cache the user's selection (i.e., to get around the fact
thatthe getSelection() usually returns the wrong value). That is, the
selection cached by the listener is correct, but during Eclipse's
viewer.refresh() execution, a selection-change-event is sent:
org.eclipse.jface.viewers.Viewer$2.run(Viewer.java:162)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:857)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:46)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:193)
at org.eclipse.jface.viewers.Viewer.fireSelectionChanged(Viewer.java:160)
at
org.eclipse.jface.viewers.StructuredViewer.updateSelection(StructuredViewer.java:2047)
at
org.eclipse.jface.viewers.StructuredViewer.handleInvalidSelection(StructuredViewer.java:1102)
at
org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1381)
at
org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330)
at
org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1431)
at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:503)
at
org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1390)
That updates my cached selection, and the obvious workaround sometimes
fails (not yet clear why).
What *seems* to be happening in that call-stack is that the
updateSelection() causes the same *index* to be reset (i.e., if the
getSelection() returns { ItemFoo }, the updateSeletion() does not select
ItemFoo, but selects the n-th item when n is the index of ItemFoo in the
Table *before* the sort.
(It is also not the same as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=117175 because that bug
reports that when the user selects non-contiguous items, using
SHIFT-click, the resultant selection is missing the intervening items;
my problem concerns single, or small contiguous selections of items, all
of which have already been displayed. Similarly, it is not the same as
https://bugs.eclipse.org/bugs/show_bug.cgi?id=128561 because that bug
reports on the problem caused by *programmatically* selecting all
elements ...).
On the other hand it is like the "inverse" of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=207846 -- that bug
complains that setSelection() causes a 'reveal'; I in fact want the
reveal, but the *wrong* item is selected.
There was a hint
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=117175#c5) that
ILazyContentProvider may get abandoned ... is my problem solvable within
the existing framework? Is it fixed in some later release than I am
using? Is there a chance it will get fixed?