Community
Participate
Working Groups
Build Identifier: M20110210-1200 The indices in a ListDiff event fired by EObjectObservableList during a multi-remove operation (removeAll()/clear()) are incorrect. The problem (as I can see it) is in the implementation of the Notification.REMOVE_MANY case in the Adapter created in EObjectObservableList#firstListenerAdded() The index computation is incorrect. It should take the removed element into account not just blindly increment the index. (see how the diff is calculated in WritableList#clear()) Another problem is with clear(). The notification event index will be set to Notification.NO_INDEX which is -1. (see NotifyingListImpl#clear()) Reproducible: Always Steps to Reproduce: Container container = FACTORY.createContainer(); container.getComponents().add(FACTORY.createComponent()); container.getComponents().add(FACTORY.createComponent()); IObservableList list = EMFObservables.observeList(container, PACKAGE.getContainer_Components()); Listener listener = new Listener(); list.addListChangeListener(listener); list.clear(); assertEquals(Arrays.asList(0, 0), listener.getIndices()); // The actual indices are [-1, 0]
Created attachment 199630 [details] The complete test project Contains the eclipse project directory (ECore model, generated artifacts and the full test case).
Created attachment 199687 [details] Patches to address the issue. I've not tested these changes, but the idea is that the REMOVE_MANY notification includes an array with the positions of the removals, except in the case where the array is basically redundant because it's just the sequence of values 0..n, i.e., when you clear the list.
Tom, The same issue comes up in EMFResourceContentProperty and EWritableList whereas EMFPropertyListener is done correctly.
Created attachment 200999 [details] Working in Progress Patch * I've synced the listeners to be all the same than the one in EMFPropertyListener - Ed it looks like there's been also a difference in the resolve case can you you clarify which one is correct (i currently assumed the one in EMFPropertyListener) * I've ported your patch to our test suite * TODOs: - The writeable list test fails (maybe a bug in core databinding??) - add test for property-api - add test for edit-api
Created attachment 201009 [details] Working in Progress Patch I've now added a test for the property and there the list-diff is like the one in WritableList. The logic in there seems to be [1,0] I think we should yield the same in our listeners not?