FLEX-35043 PROBLEM: The assumptions in SF_ORIG_list_events_tester.List_events_collectionKind_move made obvious another problem caused by FLEX-34885: calling itemUpdated(item) did not reposition the item according to the sorting rules (unless the Sort had a customCompareFunction). CAUSE: FLEX-34885 assumed that the initial logic of checking for !updateEntry.property was to detect when entire objects were replaced with others in the collection. However, it was also detecting when the developer signalled that something (undefined) about an object had changed, and they wanted the sorting / filtering to be reapplied.
SOLUTION: now we call moveItemInView() also when updateEntry.property is null and there are no oldValue or newValue specified in the CollectionEvent.
NOTES: -also updated ListCollectionView_PropertyChangeEvent_Tests and added a new function for objects which are not bindable. As expected, there is a failure without this change to ListCollectionView, and with the change all unit tests pass. -made explicit a conversion from Object into Boolean in a call to moveItemInView(). -reformated event instantiations to be on one line. -made some minor changes to SF_ORIG_ListBasic.mxml, which is used by SF_ORIG_list_events_tester.
FLEX-34885 Added a new unit test class, ListCollectionView_PropertyChangeEvent_Tests, that not only tests a few scenarios to make sure that ListCollectionView reacts as expected to PropertyChangeEvents, but also makes explicit 2 of the consequences of manually dispatching PropertyChangeEvents through the VOs in the list without specifying a "property" and an "oldValue" in the PropertyChangeEvent: 1. null is assumed to have been replaced in the collection by that VO, so it will be removed if it already exists. This may be unexpected to developers. 2. if there's a customCompareFunction in the Sort object, it will be called with null as one of the arguments. This may again be unexpected to developers. NOTES: -also removed some whitespace and improved asdocs.