Run this application, and you'll see the ComboBox displaying the value New YorkÉ while we would expect Illinois. We forgot about the order in which objects' properties (cbx_1) get initialized. In particular, the value property is initialized before the dataProvider. And, since during dataProvider initialization ComboBox, by default, selects the first item, the work performed by our value setter is wasted. You can prove the point by just trading places of value and dataProvider in the above application code.

Should we rely on the order of attributes in MXML components? Apparently not. Especially when Flex offers an excellent mechanism to coordinate the updates to multiple properties of the control Ð the commitProperties() method.

Here is how it works: whenever you need to modify a property raise some indicator, store the value in the temporary variable and call invalidateProperties(), like in the following snippet:

    private var candidateValue:Object;
    private var valueDirty:Boolean = false;
    public function set value(val:Object) : void {
       candidateValue = val;
       valueDirty = true;
       invalidateProperties();
    }

In response to invalidateProperties() Flex will schedule a call of commitProperties() for a later execution, so that all property changes deferred in the above manner can be consolidated in a single place and in the pre-determined order:

   override protected function commitProperties():void {
     super.commitProperties();

     if (dataProviderDirty) {
       super.dataProvider = candidateDataProvider;
       dataProviderDirty = false;
     }

     if (valueDirty) {
       applyValue(candidateValue);
       valueDirty = false;
     }
     }

Aside from co-ordinating updates to different properties, this coding pattern helps to avoid multiple updates to the same property and, in general, allows setter methods to return faster, improving the overall performance of the control. The entire code of our "value-aware" ComboBox is presented in Listing 4:

<?xml version="1.0" encoding="utf-8"?>
<mx:ComboBox xmlns:mx="http://www.adobe.com/2006/mxml" >
<mx:Script>
   <![CDATA[

   private var candidateValue:Object;
   private var valueDirty:Boolean = false;
   private var candidateDataProvider:Object;
   private var dataProviderDirty:Boolean = false;
   private function applyValue(val:Object):void {
     if ((val != null) && (dataProvider != null)) {

       for (var i : int = 0; i < dataProvider.length; i++) {
         if ( val == dataProvider[i].data || val == dataProvider[i].label) {
           selectedIndex = i;
           return;
     } } }
     selectedIndex = -1;
   }

   public function set value(val:Object) : void {
     candidateValue = val;
     valueDirty = true;
     invalidateProperties();
   }
   override public function set dataProvider(value:Object):void {
     candidateDataProvider = value;
     dataProviderDirty = true;
     invalidateProperties();
   }

   override protected function commitProperties():void {
     super.commitProperties();

     if (dataProviderDirty) {
       super.dataProvider = candidateDataProvider;
       dataProviderDirty = false;
     }

     if (valueDirty) {
       applyValue(candidateValue);
       valueDirty = false;
     }
   }
   ]]>
</mx:Script>
</mx:ComboBox>

Now everything works as expected. The screenshot of the running application is presented Figure 1.

If you change the ComboBox selection, the top label, which initially contains Current bound value is "IL" will change accordingly. No miracles here, a regular Flex data binding one would say. Indeed, good things are easy to take for granted. Still, we have not provided any binding declarations or binding code in our ComboBox. So why does it work? It works because the original Flex definition of value getter ComboBox has already been marked with metadata tag ["Bindable"], which makes the property bindable (you do not have to have a setter to be bindable):

[Bindable("change")]
[Bindable("valueCommitted")]

But wait, you may say, these binding definitions indicate that data modifications bound to value property get triggered in response to events change or valueCommitted. Yet our value setter does not contain a single dispatchEvent call. Where is the catch? Events are dispatched inside the code that assigns selectedIndex. This assignment results in invocation of selectedIndex setter, which ultimately dispaches events. Remember, Flex is a framework. You have to read the Flex code to take full advantage of it.