I'm using the Cairngorm framework. I'm a newbie in Flex, also.
Dispatching a simple CairngormEvent, a command that modifies a property using a setter is executed. This setter has just two lines of code: asign the received value to an internal property, and dispatch the event that the getter is associated to. Why is the getter executing two times? Has Cairngorm something to do with this problem?
Also... if I have this Label component
<mx:Label id="myLabel" text={myVar} />
why is the getter of "myVar" executing 4 times when the application is loaded? Is it normal?
I hope you can help me with these questions. Thank you!
Thanks Flex harUI!
I've been reading for a while and testing a bit more about this "problem". Is data binding something a programmer should avoid until is strictly necessary (never) and should every property change be handled by event handlers?
Maybe customizing the event for the [Bindable] metatag a best way to avoid?
As I say, I'm a newbie in flex, but I can see it really isn't very efficient... to say, this simple "program":
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical"
width="200" height="200"
xmlns:utils="utils.*">
<mx:Number id="num">0</mx:Number>
<utils:BindableClass id="bc" />
<mx:Label id="textTest" text="{bc.counter}"/>
<mx:Button id="myButton" click="bc.counter = num++" label="¡Sum!"/>
</mx:Application>
using this class:
package utils
{
public class BindableClass
{
private var _counter:Number;
public function BindableClass()
{
_counter = 100;
}
[Bindable]
public function get counter():Number
{
return _counter;
}
public function set counter(value:Number):void
{
_counter = value;
}
}
}
I just don't understand why the getter executes 4 times each time I click in button myButton.
Do you think is normal?
Thanks again! ![]()
North America
Europe, Middle East and Africa
Asia Pacific
Copyright © 2012 Adobe Systems Incorporated. All rights reserved.
Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-14-2009).