It might be easier to send me your SWF. I think I'm synced too, but we are getting different results. When you say 4.10, I assume you mean the develop branch? For me, in moveItemsInView, you go into addItemsToView, and it goes down the sort case and finds the item in localIndex, which then causes it to be re-added to the localIndex. AddItemsToView already has a filterFunction test in it, which is why I think the code path is supposed to hit that and not add the item. I suppose you could add a test to updateEntry.move, but I think the safer fix (if it works) is to re-order the tests in addItemsToView to test filter before sort.
On 5/20/13 7:43 PM, "Justin Mclean" <[email protected]> wrote: >Hi, > >> Hmm. I pulled all the latest code. Are you synced up as well? >All synced. > >> Just to make sure I understand your situation: This test app does >>report >> '3' on the latest code for you, but the mustella test keeps reporting >>'4'? >Correct. > >> Or set breakpoint on >> ListCollectionView:listChangeHandler and see if it goes into >> moveItemsIntoView, >Yes it does via the dispatch of the property change event which removes >the item (leaving 3 items). > >moveItemsIntoView is called if sort is effected or there a filter >function: > updateEntry.move = > updateEntry.move > || filterFunction > || !updateInfo.property > || (sort && >sort.propertyAffectsSort(String(updateInfo.property))); > >> properly removes the item, but in addItemsToView it goes down the sort >>path so the filter test is never run? >Yes looks like the filter test is never run but the item is always >removed if there is a filter (in 4.10). > >I think the code should be this: > > updateEntry.move = > updateEntry.move > || filterFunction && filterFunction(item) > || !updateInfo.property > || (sort && >sort.propertyAffectsSort(String(updateInfo.property))); > >Mind that still doesn't explain why the corrected mustella test is still >failing. > >Thanks, >Justin
