Composite components are custom components made up of two or more components. A common composite component is a form that contains several text fields, labels, and buttons. Composite components can be MXML files or ActionScript classes.

By default, you can record operations on all instrumented child controls of a container. If you have a Button control inside a custom TitleWindow container, the QA professional can record actions on that Button control just like on any Button control. You can, however, create a composite component in which some of the child controls are instrumented and some are not. To prevent the operations of a child component from being recorded, you override the following methods:

• numAutomationChildren getter
• getAutomationChildAt()

The numAutomationChildren property is a read-only property that stores the number of automatable children that a container has. This property is available on all containers that delegate implementation classes. To exclude some children from being automated, you return a number that is less than the total number of children.

The getAutomatedChildAt() method returns the child at the specified index. When you override this method, you return null for the unwanted child at the specified index, but return the other children as you normally would.

The following custom composite component is written in ActionScript. It consists of a VBox container with three buttons (OK, Cancel, and Help). You cannot record the operations of the Help button. You can record the operations of the other Button controls, OK and Cancel. The following example sets the values of the OK and Cancel buttons' automationName properties. This makes those button controls easier to recognize in the automated testing tool's scripts.

// MyVbox.as
package { // Empty package
    import mx.core.UIComponent;
    import mx.containers.VBox;
    import mx.controls.Button;
    import mx.automation.IAutomationObject;
    import mx.automation.delegates.containers.BoxAutomationImpl;

    public class MyVBox extends VBox {
        public var btnOk : Button;
        public var btnHelp : Button;
        public var btnCancel : Button;

        public function MyVBox():void { // Constructor
        } 
        
        override protected function createChildren():void {
            super.createChildren();
                
            btnOk = new Button();
            btnOk.label = "OK";
            btnOk.automationName = "OK_custom_form";
            addChild(btnOk);
    
            btnCancel = new Button();
            btnCancel.label = "Cancel";
            btnCancel.automationName = "Cancel_custom_form";
            addChild(btnCancel);
    
            btnHelp = new Button();
            btnHelp.label = "Help";
            btnHelp.showInAutomationHierarchy = false;
            addChild(btnHelp);      
        } 
        
        override public function get numAutomationChildren():int {
            return 2; //instead of 3
        }

        override public function 
            getAutomationChildAt(index:int):IAutomationObject {
            switch(index) {
                case 0:
                    return btnOk;
                case 1:
                    return btnCancel;
            }
            return null;
        }                
    } // Class
} // Package

To make this solution more portable, you could create a custom Button control and add a property that determines whether a Button should be testable. You could then set the value of this property based on the Button instance (for example, btnHelp.useInAutomation = false), and check against it in the overridden getAutomationChildAt() method, before returning null or the button instance.