[
https://issues.apache.org/jira/browse/FLEX-35043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Chira updated FLEX-35043:
-------------------------------
Description:
See the unit tests in
mx/collections/ListCollectionView_PropertyChangeEvent_Tests.as which are tagged
(in a comment, above the function) with FLEX-35043.
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. (That's because the
"property" value of the PropertyChangeEvent was null, which 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).
was: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. (That's because the
"property" value of the PropertyChangeEvent was null, which 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).
> 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
>
> See the unit tests in
> mx/collections/ListCollectionView_PropertyChangeEvent_Tests.as which are
> tagged (in a comment, above the function) with FLEX-35043.
> 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. (That's because the
> "property" value of the PropertyChangeEvent was null, which 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).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
