Custom Composite Control not rendering correctly for only 0.5-1 sec after being added back into a VGROUP

Question

I am moving away from MXML and have built a custom component control within ActionScript.

I have the control displaying correctly.

Answer 1

I'll try to give you an example of what I mean with the Spark skinning architecture we've discussed in the comments above. It's not directly an answer to your question, but I thought you might find it interesting. I will have to make it somewhat simpler than your component for brevity's sake and because you seem to have stripped out some of the code for your question so I can't know exactly what it's supposed to do.

This will be a component that will let you toggle between a normal and an expanded state through the click of a Button. First we'll create the skin class. Normally you'd create the host component first, but it'll be easier to explain this way.

<!-- my.skins.ComboBoxMultiSelectSkin -->
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009" 
        xmlns:s="library://ns.adobe.com/flex/spark"
        height.normal="25" height.expanded="200">

    <fx:Metadata>
        [HostComponent("my.components.ComboBoxMultiSelect")]
    </fx:Metadata>

    <s:states>
        <s:State name="normal" />
        <s:State name="expanded" />
    </s:states>

    <s:layout>
        <s:HorizontalLayout gap="0" />
    </s:layout>

    <s:ComboBox id="comboBox" width="100%" />
    <s:Button id="toggleButton" width="20"
              icon.normal="@Embed('../Assets/Icons/plus-16.png')"
              icon.expanded="@Embed('../Assets/Icons/minus-16.png')"/>

</s:Skin>

Thus we've set up completely how your component will look and how it will lay out. Do you feel your headaches dissipating? I for one find this quite elegant. We have the two states and the height of the component will adjust to the currently selected state as will the icon of the Button. How and when the state is toggled is component behaviour and will be defined in the host component.

Now let's create that host component in plain ActionScript. For this we'll extend SkinnableComponent (note that it could also extend your ReportControl if that would extend SkinnableComponent instead of UIComponent).

[SkinState("normal")]
[SkinState("expanded")]
public class ComboBoxMultiSelect extends SkinnableComponent {

    [SkinPart(required="true")]
    public var toggleButton:IEventDispatcher;

    [SkinPart(required="true")]
    public var comboBox:ComboBox;

    private var expanded:Boolean;

    override protected function partAdded(partName:String, instance:Object):void {
        super.partAdded(partName, instance);

        switch (instance) {
            case toggleButton:  
                toggleButton.addEventListener(MouseEvent.CLICK, handleToggleButtonClick); 
                break;
            case comboBox:
                comboBox.addEventListener(IndexChangeEvent.CHANGE, handleComboSelection);
                break;
        }
    }

    private function handleToggleButtonClick(event:MouseEvent):void {
        toggleExpanded();
    }

    private function handleComboSelection(event:IndexChangeEvent):void {
        //handle comboBox selection
    }

    protected function toggleExpanded():void {
        expanded = !expanded;
        invalidateSkinState();
    }

    override protected function getCurrentSkinState():String {
        return expanded ? "expanded" : "normal";
    }
}

Allright, there's a lot more going on here.

• First look at the SkinState metadata declarations: when a skin class is assigned to the component, the compiler will check whether that skin has the required states implemented.
• Then the SkinPart declarations: the name of the property on the host component must exactly match the id of the tag in the skin class. As required is set to true the compiler will check whether these components do really exist in the skin. If you want optional skin parts, you set it to false.
• Note that the type of toggleButton is IEventDispatcher: from the host component's point of view, all toggleButton has to do, is dispatching CLICK events. This means that we could now create a skin with <s:Image id="toggleButton" source="..." /> and the whole thing would keep working the same way. See how powerful this is?
• Because the skinpart properties are not assigned immediately, we override the partAdded() method which will be executed whenever a component becomes available. In most cases this is the place where you hook up your event listeners.
• In the toggleExpanded() method, we toggle the boolean just like the component in your question, however we only invalidate the skin state. This will cause the skin to call the getCurrentSkinState() method and update its state to whatever value is returned.

Et voilà! You have a working component with the behaviour nicely separated into an actionscript class and you didn't have to worry about the layout intricacies. And if you ever wish to create a component with the same behaviour, but it should expand horizontally instead of vertically: just create a new skin that adjusts the width instead of the height and assign that to the same host component.

Oh wait! I nearly forgot to tell you how to assign the skin to the components. You can do it either inline:

<c:ComboBoxMultiSelect skinClass="my.skins.ComboBoxMultiSelectSkin" />

or through styling:

@namespace c "my.components.*";

c|ComboBoxMultiSelect {
    skinClass: ClassReference("my.skins.ComboBoxMultiSelectSkin")
}

Answer 2

Thank you both so much for your answers! The consideration and attention to detail in explaining the concepts is awesome! Très bien!

@RIAstar However due to the amount of code already in place, changing my architecture (separating visual element from behavioural) would force to large a re-factor of the code and would cost to much for a feature that hasn't been explicitly requested. (visual representation of the control being able to change at runtime) It certainly is interesting and I will be adding that into a future version.

That said, I think I've been able to find a solution to my problem. I decided to build off of @SunilD.'s suggestion of validating the control before it's added back in. A hack I know, but humans aren't perfect and thus the code aint either. ;-)

When looking at the control, I noticed it was only the button that was having issues with rendering its image. So to test, I added and removed JUST a button instance with an icon, and I saw the same behaviour! (regardless of how comboBoxMultiSelect was implemented) I ALSO noticed that I didn't see the button do this when it was first created. So why not just reconstruct the button when it gets removed from the display list?

I ended up wiring comboBoxMultiSelect to the FlexEvent.REMOVE event, destroy the button reference, create a new one, and add it back in with AddChild(). Below is an explanation of the event.

"Dispatched when the component is removed from a container as a content child by using the removeChild(), removeChildAt(), removeElement(), or removeElementAt() method. If the component is removed from the container as a noncontent child by using the rawChildren.removeChild() or rawChildren.removeChildAt() method, the event is not dispatched.

This event only dispatched when there are one or more relevant listeners attached to the dispatching object."

Sure enough, this fixed the icon from displaying incorrectly and explains what happening. For some reason the button is taking more than one render event to apply its style when it's added back in. Anyone else able to replicate this behaviour?

I guess the real question now is "what is the best way to remove and add-back-in a button to the display list, so that its embedded icon is unaffected?"

Answer 3

One thing that stands out is in your implementation of updateDisplayList(). As you know, this is where your component should size and position it's child objects (and/or do any programatic drawing).

But rather than set the child object's width/height directly, you should use one of the Flex lifecycle methods: setActualSize() or setLayoutBoundsSize(). Use setLayoutBoundsSize() with spark components.

When you set a Flex component's width/height, the component will invalidate itself so that on the next update cycle it can be re-rendered. But since you are trying to render the component in updateDisplayList() you should be careful to not invalidate your child objects inside this method.

The setActualSize() and setLayoutBoundsSize() methods set the width/height on a Flex component, but do not invalidate the component.

override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
    super.updateDisplayList(unscaledWidth, unscaledHeight);
    _horizontalGroup.setLayoutBoundsSize(unscaledWidth, unscaledHeight);
    // if you wanted to position objects, you would set their x/y coordinates
    // here with the move() or setLayoutBoundsPosition() methods
}

Note, it looks like some child objects are being sized in createChildren() as well ... and it's not really clear what the base Flex component is in this case (what class does ReportControl extend?

Doing it this way may get rid of that rendering glitch. It will most certainly execute less code than if you set width/height properties directly.

[Edit]

It may be an interaction with the HGroup which is kind of unnecessary in this component. While I think making components this way is fun, it can be more tedious... which is why @RIAStar is wisely pointing out another approach.

Some further ideas, if you want to continue down this path:

1) Take a look at the sizing you are doing in createChildren() - for example, the HGroup is given a percentWidth, but in updateDisplayList() it is given a fixed width (this may be a red herring, but I would not set the percentWidth).

2) You might be able to trick the component into validating itself after you remove it or before you re-add it. A hacky hunch that may be a waste of time.

3) Remove the 'HGroup' from your component. It's kind of unnecessary: the layout requirements are simple enough to do w/a few lines of Actionscript. Your mileage will vary as the layout requirements get more complex!

In createChildren() add the combo box and button directly to the UIComponent. Then size and position them in updateDisplayList(), something like this:

override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
    super.updateDisplayList(unscaledWidth, unscaledHeight);
    var padding:Number = 10;
    var gap:Number = 0;

    // make the ComboBox consume all of the width execpt for 20px and gap + padding
    var availableWidth:Number = unscaledWidth - 20 - gap - (2*padding);
    _drp.setLayoutBoundsSize(availableWidth, unscaledHeight); // combo box 100% width
    _btnMultiple.setLayoutBoundsSize(20, unscaledHeight); // button is 20px wide

    // now position them ...
    // probably should not use 0, rather calculate a Y coordinate that centers them
    // in the unscaledHeight
    _drp.setLayoutBoundsPosition(padding, 0);
    _btnMultiple.setLayoutBoundsPosition(unscaledWidth - padding - 20, 0);
}