[
https://issues.apache.org/jira/browse/FLEX-35043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Chira resolved FLEX-35043.
--------------------------------
Resolution: Fixed
> Unexpected behaviour of ListCollectionView.itemUpdated() when only one
> parameter supplied
> -----------------------------------------------------------------------------------------
>
> Key: FLEX-35043
> URL: https://issues.apache.org/jira/browse/FLEX-35043
> Project: Apache Flex
> Issue Type: Bug
> Components: Collections
> Affects Versions: Apache Flex 4.15.0
> Reporter: Mihai Chira
> Assignee: Mihai Chira
> Fix For: Apache Flex 4.16.0
>
>
> See the unit tests in
> mx/collections/ListCollectionView_PropertyChangeEvent_Tests.as which are
> tagged (in a comment, above the function) with FLEX-35043.
> FLEX-34885 invalidated two previous assumptions:
> # When calling itemUpdated(item) on a collection with only the first
> parameter provided (which developers usually do to signal that some -
> unspecified - properties of the item have changed),
> ListCollectionView.handlePropertyChangeEvents() would treat that as if the
> object has been just introduced to the collection, replacing a null value -
> since oldValue was null, and property was also null. (When the "property"
> value of the PropertyChangeEvent was null, it was taken to mean that the
> oldValue - which was also null - was changed into that item, i.e. the object
> reference changed in the collection, not just one of the object's
> properties.) As such, it would try to remove that supposedly existing null
> value from the collection (and sometimes a null does exist, but shouldn't be
> removed).
> # The assumptions in
> SF_ORIG_list_events_tester.List_events_collectionKind_move (which started
> failing) show that calling itemUpdated(item) does not reposition the item
> according to the sorting rules anymore (unless the Sort has a
> customCompareFunction).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
