selectionChanged and listChanged sent out of order

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

selectionChanged and listChanged sent out of order

Michael Heuer
Hello,

See attached; when run it prints out

$ java -classpath ... ListSelectionIssue
...
   Value 5 (5)  selected
   Value 6 (6)  deselected
   Value 7 (7)  deselected
heard selectionChanged 4 - 5 at 98962132731115
   Value 5 (4)  selected
   Value 6 (5)  deselected
heard listChanged event ListEvent: X0-1 at 98962133269172
   delete index 0
heard selectionChanged 3 - 4 at 98967132700664
   Value 5 (3)  selected
   Value 6 (4)  deselected
...

Note that the listChanged event is received after the selectionChanged
event.  The index lookup is still correct (the selected value at index
4 is "Value 5"), so that means the eventList must have been modified
before the selectionChange event was sent.


I'm implementing a view that uses an EventList + ListSelection as its
model and selection model respectively.  The view is reliant on
listChanged events to synchronize model indices to view indices.
Since the selectionChanged event comes too early, maintaining the
selection is impossible.

Is there a way to force the listChange event notification to happen
before the selectionChanged event?

Alternatively, is there some way of synchronizing the indicies of
another List with an EventList without relying on listChanged events?

Thanks,

   michael

ListSelectionIssue.java (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: selectionChanged and listChanged sent out of order

hbrands
Administrator
Hi Michael,

by default, Glazed Lists delivers ListEvents to (independent) listeners of an EventList in the order they were added to the list.
In your example, first ListSelection will add its internal listener to the EventList, after that you add your own ListEventListener.
Consequently, ListSelection will receive ListEvents first, than your ListEventListener.

You have to options to change this:

a) if you are in control of adding the listeners in the correct order, you should do that, e.g. adding your listener before creating ListSelection.

b) tell GlazedLists about the intended order:

// indicate the dependency between your ListEventListener & the ListSelection
// this ensures the ListEventPublisher delivers events to myListEventListener
// *before* the ListSelection, which is the intended relative order of notification
eventList.getPublisher().setRelatedListener(listSelection, myListEventListener);

Hope this helps,
Holger

2012/2/2 Michael Heuer <[hidden email]>
Hello,

See attached; when run it prints out

$ java -classpath ... ListSelectionIssue
...
  Value 5 (5)  selected
  Value 6 (6)  deselected
  Value 7 (7)  deselected
heard selectionChanged 4 - 5 at 98962132731115
  Value 5 (4)  selected
  Value 6 (5)  deselected
heard listChanged event ListEvent: X0-1 at 98962133269172
  delete index 0
heard selectionChanged 3 - 4 at 98967132700664
  Value 5 (3)  selected
  Value 6 (4)  deselected
...

Note that the listChanged event is received after the selectionChanged
event.  The index lookup is still correct (the selected value at index
4 is "Value 5"), so that means the eventList must have been modified
before the selectionChange event was sent.


I'm implementing a view that uses an EventList + ListSelection as its
model and selection model respectively.  The view is reliant on
listChanged events to synchronize model indices to view indices.
Since the selectionChanged event comes too early, maintaining the
selection is impossible.

Is there a way to force the listChange event notification to happen
before the selectionChanged event?

Alternatively, is there some way of synchronizing the indicies of
another List with an EventList without relying on listChanged events?

Thanks,

  michael

Reply | Threaded
Open this post in threaded view
|

Re: selectionChanged and listChanged sent out of order

Michael Heuer
Hello Holger,

Option b) worked for me.  Thank you for your help.

The relevant code is in svn at

http://dishevelled.svn.sourceforge.net/viewvc/dishevelled/trunk/eventlist-view
http://dishevelled.svn.sourceforge.net/viewvc/dishevelled/trunk/piccolo-eventlist-view

among other modules, and here is an example

http://dishevelled.svn.sourceforge.net/viewvc/dishevelled/trunk/piccolo-eventlist-view-examples/src/main/java/org/dishevelled/piccolo/eventlist/view/examples/IdEventListNodeExample.java?revision=1075&view=markup

   michael


On Sat, Feb 4, 2012 at 11:35 AM, Holger Brands
<[hidden email]> wrote:

> Hi Michael,
>
> by default, Glazed Lists delivers ListEvents to (independent) listeners of
> an EventList in the order they were added to the list.
> In your example, first ListSelection will add its internal listener to the
> EventList, after that you add your own ListEventListener.
> Consequently, ListSelection will receive ListEvents first, than your
> ListEventListener.
>
> You have to options to change this:
>
> a) if you are in control of adding the listeners in the correct order, you
> should do that, e.g. adding your listener before creating ListSelection.
>
> b) tell GlazedLists about the intended order:
>
> // indicate the dependency between your ListEventListener & the
> ListSelection
> // this ensures the ListEventPublisher delivers events to
> myListEventListener
> // *before* the ListSelection, which is the intended relative order of
> notification
> eventList.getPublisher().setRelatedListener(listSelection,
> myListEventListener);
>
> Hope this helps,
> Holger
>
>
> 2012/2/2 Michael Heuer <[hidden email]>
>>
>> Hello,
>>
>> See attached; when run it prints out
>>
>> $ java -classpath ... ListSelectionIssue
>> ...
>>   Value 5 (5)  selected
>>   Value 6 (6)  deselected
>>   Value 7 (7)  deselected
>> heard selectionChanged 4 - 5 at 98962132731115
>>   Value 5 (4)  selected
>>   Value 6 (5)  deselected
>> heard listChanged event ListEvent: X0-1 at 98962133269172
>>   delete index 0
>> heard selectionChanged 3 - 4 at 98967132700664
>>   Value 5 (3)  selected
>>   Value 6 (4)  deselected
>> ...
>>
>> Note that the listChanged event is received after the selectionChanged
>> event.  The index lookup is still correct (the selected value at index
>> 4 is "Value 5"), so that means the eventList must have been modified
>> before the selectionChange event was sent.
>>
>>
>> I'm implementing a view that uses an EventList + ListSelection as its
>> model and selection model respectively.  The view is reliant on
>> listChanged events to synchronize model indices to view indices.
>> Since the selectionChanged event comes too early, maintaining the
>> selection is impossible.
>>
>> Is there a way to force the listChange event notification to happen
>> before the selectionChanged event?
>>
>> Alternatively, is there some way of synchronizing the indicies of
>> another List with an EventList without relying on listChanged events?
>>
>> Thanks,
>>
>>   michael