tags:

views:

44

answers:

2

Hello there.

Since I found the webpages explaning the bindable propety quite confusing,so I would like to post my question here,which is quite simple,if I declare a variable to be bindable,does that mean whenever I changed the value of this variable in another class,all appearence of this variable will be synchronized to be the same value at the same time?

Say,if boolean variable "select" is declared to be bindable in Class A and default to be false,and we have an if statement in class A like if(select).

Then in another class,we changed the value of "select" to be true,will that if(select) statement pass the test ?

Also,how about the following setter method that is defined to be bindable:

[Bindable]
public function set isShowingAvg(b:Boolean):void
{
   _isShowingAvg = b;

   hasChanged();
}

Does this code imply that changing the value of _isShowingAvg is also going to be broadcasted?

Thanks in advance.

Thanks for your idea.

+3  A: 

Declaring a property as Bindable means that when you change the value, an event will get broadcasted. This event enables data binding, but it's not necessarily automatic.

If the consuming class is MXML and you use brackets, like this:

<mx:Button enabled="{selected}" />

Then the MXML compiler will generate the appropriate binding code and anytime selected changes, enabled will also get changed.

If you're using it outside MXML then you'll either subscribe to the event to detect changes or use BindingUtils.

Sam
+1  A: 

In your example I think you need to mark the getter [Bindable] and not the setter.

example:

public static const SHOWING_AVG_CHANGED:String = "showingAvgChangedEvent";

 [Bindable(event="showingAvgChangedEvent")]
public function get isShowingAvg():Boolean
{
   return _isShowingAvg;
}

public function set isShowingAvg(isShowing:Boolean):void
{
   _isShowingAvg = isShowing;
   dispatchEvent(new Event(SHOWING_AVG_CHANGED));
}
hering
This is incorrect. [Bindable] can go on either the getter, or the setter. Also, manual events are fine, but not required if the property is read/write.
Marty Pitt
@Marty Pitt, manual events are much more efficient and should pretty much always be used. If you don't know why, try creating a class with a few `[Bindable]` properties and then another that subscribes to several of them. Them step through the setters to see what happens when the `propertyChanged` event is broadcast. Instead of just the one bound property being triggered, all bound properties are triggered and each checks *is this the one I care about?* which is crazy inefficient. Try multiplying that by dozens of properties and you the problem gets exponentially worse.
Sam