Re:Re: Re: Re: Different behavior between mx and spark

2014-07-17 Thread DarkStone
Hi, >Isn't this what happens to every single inherited behavior? Aren't >components created with this in mind? To provide multiple options on >case-by-case scenario? Well, the enabled setter is a functionality, the default behavior of this functionality should be suit for common use case not ed

Re: Re: Re: Different behavior between mx and spark

2014-07-17 Thread João Fernandes
On 17 July 2014 12:43, DarkStone wrote: > Hi > > >I repeat, my plan is to keep the current behavior as the default, only if > >you enable the new functionality trough a flag/style/whatever... > Ok, I got your idea. Adding through a flag/style/whatever is doable, but > from the perspective of the

Re: Re: Different behavior between mx and spark

2014-07-17 Thread João Fernandes
I repeat, my plan is to keep the current behavior as the default, only if you enable the new functionality trough a flag/style/whatever, the new behavior will kick in so current projects will behave like they always did. As I told you previously, subclassing is not an option since I plan to have al