The setter does not have to call dispatchevent in this case because by convention, the list classes set listData then set data which will fire the dataChange. This is required since we have to set both in order for the two properties to remain synced up. So you don't want or need to dispatch the event in the listData setter.
________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of agggka Sent: Friday, September 21, 2007 2:31 AM To: [email protected] Subject: [flexcoders] ItemRenderer : listData and dataChange event hello there, Using the advices found on Alex Harui's blog, I wrote a simple ItemRenderer. I stumble upon a weird (but documented) flex behavior, the 'listData' property is describted as [Bindable(dataChange)] but the property setter does not dispatch a dataChange event. I did check the IDropInListItemRenderer's documentation, I understand that it's the common way item renderers work, but it's bugging me. So there are my questions : What would be the consequences if the dataChange event was dispatched by both 'data' and 'listData' properties setters ? Would it introduce unexpected behaviors ? or have a noticeable cost ? Why on hell the 'listData' property was made public if it imply that it can't comply to its description (does not dispatch the event) ? Could the item renderer mechanic change someday ? thanks ^_^
