I've just been discussing this with Dermot. As I'm the person who (mostly) programmed the Amethyst Designer, he's asked me to answer this.
The current position is that the controlBarContent component is supported for Panel but not for Application. As Dermot says, you can create it in mxml but the Designer will not display it. Let me give you a bit of technical background on why this is the case.
It turns out that controlBarContent defines, in essence, a runtime (rather than design-time) behaviour. Unlike normal containers such as Panel or Group, controlBarContent is not a UIComponent. In fact, it is not a visual control of any description. For reasons which may make sense to Adobe (but I'd have to say, don't make much sense to me), controlBarContent is defined as an Array. This array is a property of Application. The controls which it contains are objects that are inserted into the array. Behind the scenes, Flex creates a group and adds Components to it in the traditional manner. But from the end programmer's perspective, the controlBarContent is
not a group and controls cannot be added to it as 'children' or 'elements'.
Since the Amethyst Designer (the Amethyst drag-and-drop design environment) is a Flex application, it has to operate within the realms of the possible as defined by Flex. Only when it receives a real container can it add child controls to them. When, as in this case, it receives an array property, it cannot automatically do this. Flash Builder does a 'special fix' whereby it pretends that controlBarContent is a container. The downside is that Flash Builder does not work like a real Flex application. That's why, when you resize controls in Flash Builder you don't see anything happening (that is, the contents of the controls are not resized dynamically) until you stop resizing. With Amethyst, you see controls respond to each resize operation pixel by pixel. So, most of the time, Amethyst gives a more accurate 'live' representation of the design than Flash Builder. But when (as here) Adobe has broken the normal rules by hiding the container behind an array property, child controls cannot be added.
In order for us to add design-time support for controlBarContent we'd have to do a pretty horrible hack (to emulate what Flash Builder does!
) that would expose the Group that is hidden behind the controlBarContent property. We've had to do few of these before - for example, to implement DataGrid columns which, once again, are non-UIComponents) and also to implement controlBarContent for Panel. The reason, by the way, that we do it for Panel but not for Application is that, as the Designer is an Application, we have to be
very cautious about doing anything which would alter the fundamental behaviour of the Application (thereby changing the behaviour of the Designer).
For the time being, we propose to leave the current level of support - namely, by allowing controlBarContent to be defined in mxml code and letting the Designer silently ignore it. We'll look at this problem again at a future date, however. I'm sure we can find a way of getting around this but it wouldn't be a 'quick fix'.
SapphireSteel Forum
Author
