About 1 year ago I did some heavy lifting with Flex charts and they can be a constant source of frustration. The fact is they are very clever inside which leads to very difficult to reason about behaviours.
One thing I noticed was that sometimes when you change data, it can actually take a few frames for it to trickle through the hierarchy. That is even if you update the dataProvider
on the legend on the same frame as when you update the series information you may not be binding to the correct version of the instance since it will change in a few frames. (i.e. the change to the Series
is asynchronous and the change to the dataProvider
is synchronous).
One quick test to see if this is your problem is just to put a hack timer in place. Set it for 100ms or so and then set your dataProvider
later -- hopefully when the changes to the Series
have worked their way to the necessary property. Another idea is to use a second button and once you visually see the new Series
use that button to trigger the assignment of the legends dataProvider
. That isn't a production ready solution but it will at least determine the nature of the problem.
If it is your problem (which I suspect but am not certain of) then start looking for events that come from all of the chart components. The event that signals the new Series
has been drawn may come from anywhere but you'll find it eventually. Good luck.
Also, the difference between:
var foo:Bar = Bar(obj); // if !(obj is Bar) throw Error
and
var foo:Bar = obj as Bar; // if !(obj is Bar) return null
is the first is best if you are certain obj
will cast to a Bar
and it will throw an exception if it isn't (in fact it would be an error if it didn't cast to a Bar
). The second (as
) is for when there is a reasonable chance obj
won't be a Bar
and it won't throw an error and will instead return null
.
Because of this behaviour Adobe recommends that the first form be used whenever possible.