hbrands
commented
20 years ago Iván -
The current behaviour is "as designed" but I agree that there may be a better way to solve this
problem.
This behaviour is the same as the behaviour of a simple JTable (ie. no Glazed Lists). When JTable
receives in insert at some index, say i, then the newly inserted row will be selected only if row i
was selected before the insertion. This behaviour has some nice properties: values inserted
within a range of selected values will themselves become selected.
But I also agree that this behaviour can be problematic. I think the solution is to add an extra
"mode" to the SelectionList. The new mode will be as you describe. Inserted values will never be
selected until done so explicitly by the user.
Due to constraints at school and at work I will be unable to add this functionality until at least
February 14th, 2004. In the worst case it will take until February 21st to complete. Hopefully then
I will get something working that solves this problem!
by jessewilson
I am delighted with the performance, flexibility and ease of use of your platform, which I am
currently evaluating for use in a table intensive application for my employer.
Our application needs to display tabular data which gets notified through JMS. That means,
ultimately, that data arrives via a callback method in out code. I am therefore using a
BasicEventList as base list, encapsulated in a SortedList and a subclass of AbstractFilterList as a
means of providing the functionality (sorting & filtering by various criteria) that we need.
The only problem so far arises with keeping selected rows between data insertions. I set the
underlying table selection model to ListSelectionModel.MULTIPLE_INTERVAL_SELECTION (anyway,
as it is the default value). A thread keeps adding rows to the table, at a rate of 10 per second (to
test performance). I have noticed that whenever I select a row, further row insertions may
modify the number of selected rows. In particular, if a new row has the same internal index as
the currently selected one, it is guaranteed I will end up with two selected rows.
That seems to be your intended behaviour as per the documentation of the class SelectionList;
however, I tried to modify it in order to suppress this behaviour to no avail. In particular, I
suppressed the lines marked inside SelectionList.notifyListChanges():
// when an element is inserted, it is selected if its index was selected
} else if(changeType == ListChangeBlock.INSERT) {
   // when selected, add the flag and fire a selection event
   if(previouslySelected)
{       flagList.add(index, Boolean.TRUE); // <--- SUPRESS       updates.appendChange(previousSelectionIndex, ListChangeBlock.INSERT); // <--- SUPRESS    // when not selected, just add the space    }
else
{ Â Â Â Â Â Â flagList.add(index, null); Â Â Â }
I tried other changes, including the method SelectionList.valueChanged(). Do you have any
suggestion to solve this problem? Is it a bug in your code? In that case, I'd be willing to help and
contribute back to your project any bugfixes I develop. I can also provide you with my testing
code, but at this stage it's really simple: the thread inserting fake data rows does so in an
invokeLater() block, and uses a java.util.Timer for scheduling data feed.
The problem does not manifest when I set the table selection model to
ListSelectionModel.SINGLE_SELECTION, by the way.
Thank you for your time and for providing the Java Community with such a promising piece of
work.
Yours
Iván Rivera RodrÃguez
[GLAZEDLISTS-15] created by jessewilson