Flex LineChart.verticalAxisRenderer anomalies

I've found some interesting behaviour when attempting to control the rendering of the vertical axis in a Flex chart. As with most UI elements in Flex, you can create charts either using MXML or ActionScript. Surprisingly, the properties of the chart are different depending on how they're created.

The ActionScript generated graph is fairly logical to deal with: nothing is pre-created so you need to do it yourself:

var vAxisRenderer:AxisRenderer = new AxisRenderer(); vAxisRenderer.axis = vAxis; vAxisRenderer.placement = "right";

_lineChart.verticalAxisRenderers.push(vAxisRenderer);

It's worth noting that only need to instantiate your own axis renderer if you want to set non-default values, otherwise you can ignore it all together. At this point it's worth noting that MXML is transformed into ActionScript at compile time. This is important in understanding the next part.

Charts generated with MXML seem to set several properties, despite actually setting them to the same value as the object's default. That can be somewhat confusing - if for example you try to add an AxisRenderer to an MXML-generated chart (as you would for an AS-generated one) you end up with two axes displayed. Although marginally annoying, the solution is simple: rather than creating a new property object you get a handle on the existing one and modify that.

Unfortunately it seems that in the case of AxisRenderers (at least on the LineChart object) the MXML transformation process uses a depricated property object - LineChart.verticalAxisRenderer:AxisRenderer (rather than LineChart.verticalAxisRenderers:Array). In order to manipulate the current renderer, first you get a handle on it:

var vAxisRenderer:AxisRenderer = _lineChart.verticalAxisRenderer as AxisRenderer;

Then proceed as normal. Because the verticalAxisRenderer property is depricated you will end up with a compiler warning.

The bottom line: don't always assume that the MXML transformation to ActionScript works as you would expect it to. Despite the apparent ease of using MXML as shorthand, it's often less hassle in the long run to use ActionScript from the outset.

comments powered by Disqus