You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by João Fernandes <jo...@gmail.com> on 2014/07/17 11:51:46 UTC
Different behavior between mx and spark
Hi, something that has bugging me is that skinnable components behave
differently from mx conter part when the object has enabled = false.
In MX all components still respond to mouseEvents while skinnable won't
because at the skinnableComponent level we have this
override public function set enabled(value:Boolean):void
{
super.enabled = value;
invalidateSkinState();
// If enabled, reset the mouseChildren, mouseEnabled to the
previously
// set explicit value, otherwise disable mouse interaction.
super.mouseChildren = value ? _explicitMouseChildren : false;
super.mouseEnabled = value ? _explicitMouseEnabled : false;
}
I plan to implement a similar mx behavior but keeping the current behavior
as the default.
Before I start doing anything, is there any reason for this difference in
behavior?
--
João Fernandes
RE: Different behavior between mx and spark
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
I believe it made for less processing / runtime overhead. But I agree there are situations you would still like to be able to use events or at least a simple toolTip text.
I know a few people that created their own child of say something like a button. They then override the enabled property and use their own enabled Boolean to keep track of it. Then they make the component look like it's disabled but changing the skin state. Override any event handlers they don't want firing.
-Mark
-----Original Message-----
From: João Fernandes [mailto:joaopedromartinsfernandes@gmail.com]
Sent: Thursday, July 17, 2014 5:52 AM
To: dev@flex.apache.org
Subject: Different behavior between mx and spark
Hi, something that has bugging me is that skinnable components behave
differently from mx conter part when the object has enabled = false.
In MX all components still respond to mouseEvents while skinnable won't
because at the skinnableComponent level we have this
override public function set enabled(value:Boolean):void
{
super.enabled = value;
invalidateSkinState();
// If enabled, reset the mouseChildren, mouseEnabled to the
previously
// set explicit value, otherwise disable mouse interaction.
super.mouseChildren = value ? _explicitMouseChildren : false;
super.mouseEnabled = value ? _explicitMouseEnabled : false;
}
I plan to implement a similar mx behavior but keeping the current behavior
as the default.
Before I start doing anything, is there any reason for this difference in
behavior?
--
João Fernandes
Re:Re: Different behavior between mx and spark
Posted by DarkStone <da...@163.com>.
Hi,
>I suppose I'd just have an 'enable helper' I could call in my app that
>would walk the display list and set children based on their parents. You
>could hook it to the global 'add' event and it'd be automatic?
I agree.
You could write a EnableHelper class as a controller to handle this, so you don't have to change code in SkinnableComponent.
DarkStone
2014-07-17
At 2014-07-17 07:48:38, "Tom Chiverton" <tc...@extravision.com> wrote:
>On 17/07/14 12:43, DarkStone wrote:
>> But after all, this is just my own opinion, others may disagree with me.
>I don't see any other way to achieve changes in behaviour in a base
>class extended by some many other ones ?
>
>I suppose I'd just have an 'enable helper' I could call in my app that
>would walk the display list and set children based on their parents. You
>could hook it to the global 'add' event and it'd be automatic?
>
>Tom
Re: Different behavior between mx and spark
Posted by João Fernandes <jo...@gmail.com>.
Thanks Alex, that was partially my initial approach, I'm going to try to
expose it as a style so I could define it using CSS so people wouldn't need
to re-implement all the skins. As stated before, my goal is to preserve the
current behavior as the default one.
On 18 July 2014 06:14, Alex Harui <ah...@adobe.com> wrote:
> Yes, this is why FlexxJS has beads. Even simple things like
> enable/disable can have different implementations.
>
> I took a quick look at SkinnableComponent. It looks like it might be
> possible for the skin to detect the state change and override the
> mouseEnabled/mouseChildren change then implement some other behavior. So
> then the set of changes would be:
>
> 1) add flag disableUsesMouseEnabled to SkinnableComponent and change the
> enabled setter to check that flag before setting mouseEnabled/mouseChildren
> 2) make a new skin base class that sets that flag an implements mx
> behavior.
>
> Then all skins that derive from that new base class will have the disabled
> behavior you desire.
>
> Of course, I could be wrongŠ
>
> -Alex
>
> On 7/17/14 6:51 AM, "João Fernandes" <jo...@gmail.com>
> wrote:
>
> >On 17 July 2014 12:48, Tom Chiverton <tc...@extravision.com> wrote:
> >
> >> On 17/07/14 12:43, DarkStone wrote:
> >> > But after all, this is just my own opinion, others may disagree with
> >>me.
> >> I don't see any other way to achieve changes in behaviour in a base
> >> class extended by some many other ones ?
> >>
> >> I suppose I'd just have an 'enable helper' I could call in my app that
> >> would walk the display list and set children based on their parents. You
> >> could hook it to the global 'add' event and it'd be automatic?
> >>
> >
> >it won't work because if parent has mouseChildren = false, even if you set
> >mouseEnabled on children, the app won't react.
> >A helper won't be able to override the default behavior because the
> >skinnableComponent behaviors always check "enabled" an prevent changing
> >mouseEnabled/mouseChildren.
> >Also, crawling the full displaylist clearly doesn't seem like the right
> >way
> >to do anything.
> >
> >--
> >
> >João Fernandes
>
>
--
João Fernandes
Re: Different behavior between mx and spark
Posted by Alex Harui <ah...@adobe.com>.
Yes, this is why FlexxJS has beads. Even simple things like
enable/disable can have different implementations.
I took a quick look at SkinnableComponent. It looks like it might be
possible for the skin to detect the state change and override the
mouseEnabled/mouseChildren change then implement some other behavior. So
then the set of changes would be:
1) add flag disableUsesMouseEnabled to SkinnableComponent and change the
enabled setter to check that flag before setting mouseEnabled/mouseChildren
2) make a new skin base class that sets that flag an implements mx
behavior.
Then all skins that derive from that new base class will have the disabled
behavior you desire.
Of course, I could be wrongŠ
-Alex
On 7/17/14 6:51 AM, "João Fernandes" <jo...@gmail.com>
wrote:
>On 17 July 2014 12:48, Tom Chiverton <tc...@extravision.com> wrote:
>
>> On 17/07/14 12:43, DarkStone wrote:
>> > But after all, this is just my own opinion, others may disagree with
>>me.
>> I don't see any other way to achieve changes in behaviour in a base
>> class extended by some many other ones ?
>>
>> I suppose I'd just have an 'enable helper' I could call in my app that
>> would walk the display list and set children based on their parents. You
>> could hook it to the global 'add' event and it'd be automatic?
>>
>
>it won't work because if parent has mouseChildren = false, even if you set
>mouseEnabled on children, the app won't react.
>A helper won't be able to override the default behavior because the
>skinnableComponent behaviors always check "enabled" an prevent changing
>mouseEnabled/mouseChildren.
>Also, crawling the full displaylist clearly doesn't seem like the right
>way
>to do anything.
>
>--
>
>João Fernandes
Re: Different behavior between mx and spark
Posted by João Fernandes <jo...@gmail.com>.
On 17 July 2014 12:48, Tom Chiverton <tc...@extravision.com> wrote:
> On 17/07/14 12:43, DarkStone wrote:
> > But after all, this is just my own opinion, others may disagree with me.
> I don't see any other way to achieve changes in behaviour in a base
> class extended by some many other ones ?
>
> I suppose I'd just have an 'enable helper' I could call in my app that
> would walk the display list and set children based on their parents. You
> could hook it to the global 'add' event and it'd be automatic?
>
it won't work because if parent has mouseChildren = false, even if you set
mouseEnabled on children, the app won't react.
A helper won't be able to override the default behavior because the
skinnableComponent behaviors always check "enabled" an prevent changing
mouseEnabled/mouseChildren.
Also, crawling the full displaylist clearly doesn't seem like the right way
to do anything.
--
João Fernandes
Re: Different behavior between mx and spark
Posted by Tom Chiverton <tc...@extravision.com>.
On 17/07/14 12:43, DarkStone wrote:
> But after all, this is just my own opinion, others may disagree with me.
I don't see any other way to achieve changes in behaviour in a base
class extended by some many other ones ?
I suppose I'd just have an 'enable helper' I could call in my app that
would walk the display list and set children based on their parents. You
could hook it to the global 'add' event and it'd be automatic?
Tom
Re:Re: Re: Re: Different behavior between mx and spark
Posted by DarkStone <da...@163.com>.
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 edge case.
Encapsuling edge case behavior to a functionality of a class is not good for post-maintenance.
I like Tom's idea, by writting an EnableHelper controller class to solve this case is much better than adding edge behavior for the enabled setter of SkinnableComponent.
DarkStone
2014-07-17
At 2014-07-17 07:58:12, "João Fernandes" <jo...@gmail.com> wrote:
>On 17 July 2014 12:43, DarkStone <da...@163.com> 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 program design, it's not a very good idea.
>>
>
>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?
>
>
>>
>> I mean today you may want to add this new behavior through a
>> flag/style/whatever, and the other day you may want to add another
>> behavior, then would you add another flag/style/whatever?
>>
>
>Again, why all components have multiple properties? Aren't those to
>consider a behavior? Unfortunately this isn't FlexJS where this kind of
>behaviors are split in different beads.
>
>
>>
>> As a result, the SkinnableComponent might have multiple behaviors to one
>> functionality (e.g. different behaviors of 'enabled' setter), this is not a
>> very good program design.
>>
>> But after all, this is just my own opinion, others may disagree with me.
>>
>> Before making any changes to the source code, it's best that we can have
>> more people to share their thoughts on this approach, don't you think : )
>>
>>
>> DarkStone
>> 2014-07-17
>>
>>
>>
>--
>
>João Fernandes
Re: Re: Re: Different behavior between mx and spark
Posted by João Fernandes <jo...@gmail.com>.
On 17 July 2014 12:43, DarkStone <da...@163.com> 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 program design, it's not a very good idea.
>
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?
>
> I mean today you may want to add this new behavior through a
> flag/style/whatever, and the other day you may want to add another
> behavior, then would you add another flag/style/whatever?
>
Again, why all components have multiple properties? Aren't those to
consider a behavior? Unfortunately this isn't FlexJS where this kind of
behaviors are split in different beads.
>
> As a result, the SkinnableComponent might have multiple behaviors to one
> functionality (e.g. different behaviors of 'enabled' setter), this is not a
> very good program design.
>
> But after all, this is just my own opinion, others may disagree with me.
>
> Before making any changes to the source code, it's best that we can have
> more people to share their thoughts on this approach, don't you think : )
>
>
> DarkStone
> 2014-07-17
>
>
>
--
João Fernandes
Re:Re: Re: Different behavior between mx and spark
Posted by DarkStone <da...@163.com>.
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 program design, it's not a very good idea.
I mean today you may want to add this new behavior through a flag/style/whatever, and the other day you may want to add another behavior, then would you add another flag/style/whatever?
As a result, the SkinnableComponent might have multiple behaviors to one functionality (e.g. different behaviors of 'enabled' setter), this is not a very good program design.
But after all, this is just my own opinion, others may disagree with me.
Before making any changes to the source code, it's best that we can have more people to share their thoughts on this approach, don't you think : )
DarkStone
2014-07-17
At 2014-07-17 07:16:09, "João Fernandes" <jo...@gmail.com> wrote:
>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
>all skinnable components with this capability.
>Once done, anyone is free to check my implementation and veto it if they
>don't like it.
>
>
>
>
>On 17 July 2014 11:57, DarkStone <da...@163.com> wrote:
>
>> Hi,
>>
>> >What I want to achieve is to replicate mx behavior on ALL spark
>> >skinnableComponents but keeping the current behavior as the default.
>>
>> IMO, the mx behavior is worse than Spark, so I don't recommend to
>> replicate mx behavior on ALL spark skinnableComponents, this is a very bad
>> idea, and this will affect all the existing Flex Spark projects.
>>
>> What you want to achieve is an edge case, not a common case, so I
>> recommend you subclass the SkinableComponent (like MySkinableComponent),
>> and override any behaviors you want, then make all of your custom
>> components by subclass your MySkinableComponent.
>>
>>
>> DarkStone
>> 2014-07-17
>>
>>
>> At 2014-07-17 06:37:37, "João Fernandes" <
>> joaopedromartinsfernandes@gmail.com> wrote:
>> >Sorry but setting mouseChildren and mouseEnabled won't work for their
>> >customSkin since skinnableComponent does check if the component is enabled
>> >and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
>> >an option in this case because it would require the entire spark
>> components
>> >to be rewritten extending the new class and monkey patching isn't an
>> option.
>> >
>> >What I want to achieve is to replicate mx behavior on ALL spark
>> >skinnableComponents but keeping the current behavior as the default.
>> >
>> >
>> >On 17 July 2014 11:14, DarkStone <da...@163.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> MX (Halo) was discontinued long time ago.
>> >>
>> >> The 'enabled' implementation of the Spark SkinnableComponent is correct,
>> >> no need to change, it's better this way, because developers can
>> explicitly
>> >> set the values of the mouseChildren and mouseEnabled for their
>> >> CustomSkin.mxml.
>> >>
>> >> If you do want to change it, you can subclass the SkinnableComponent,
>> and
>> >> override the public function set enabled(value:Boolean):void to whatever
>> >> you want it to be.
>> >>
>> >>
>> >> DarkStone
>> >> 2014-07-17
>> >>
>> >>
>> >> At 2014-07-17 05:51:46, João Fernandes" <
>> >> joaopedromartinsfernandes@gmail.com> wrote:
>> >> >Hi, something that has bugging me is that skinnable components behave
>> >> >differently from mx conter part when the object has enabled = false.
>> >> >In MX all components still respond to mouseEvents while skinnable won't
>> >> >because at the skinnableComponent level we have this
>> >> >
>> >> > override public function set enabled(value:Boolean):void
>> >> > {
>> >> > super.enabled = value;
>> >> > invalidateSkinState();
>> >> >
>> >> > // If enabled, reset the mouseChildren, mouseEnabled to the
>> >> >previously
>> >> > // set explicit value, otherwise disable mouse interaction.
>> >> > super.mouseChildren = value ? _explicitMouseChildren : false;
>> >> > super.mouseEnabled = value ? _explicitMouseEnabled : false;
>> >> > }
>> >> >
>> >> >I plan to implement a similar mx behavior but keeping the current
>> behavior
>> >> >as the default.
>> >> >
>> >> >Before I start doing anything, is there any reason for this difference
>> in
>> >> >behavior?
>> >> >
>> >> >--
>> >> >
>> >> >João Fernandes
>> >>
>> >
>> >
>> >
>> >--
>> >
>> >João Fernandes
>>
>
>
>
>--
>
>João Fernandes
Re: Re: Different behavior between mx and spark
Posted by João Fernandes <jo...@gmail.com>.
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
all skinnable components with this capability.
Once done, anyone is free to check my implementation and veto it if they
don't like it.
On 17 July 2014 11:57, DarkStone <da...@163.com> wrote:
> Hi,
>
> >What I want to achieve is to replicate mx behavior on ALL spark
> >skinnableComponents but keeping the current behavior as the default.
>
> IMO, the mx behavior is worse than Spark, so I don't recommend to
> replicate mx behavior on ALL spark skinnableComponents, this is a very bad
> idea, and this will affect all the existing Flex Spark projects.
>
> What you want to achieve is an edge case, not a common case, so I
> recommend you subclass the SkinableComponent (like MySkinableComponent),
> and override any behaviors you want, then make all of your custom
> components by subclass your MySkinableComponent.
>
>
> DarkStone
> 2014-07-17
>
>
> At 2014-07-17 06:37:37, "João Fernandes" <
> joaopedromartinsfernandes@gmail.com> wrote:
> >Sorry but setting mouseChildren and mouseEnabled won't work for their
> >customSkin since skinnableComponent does check if the component is enabled
> >and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
> >an option in this case because it would require the entire spark
> components
> >to be rewritten extending the new class and monkey patching isn't an
> option.
> >
> >What I want to achieve is to replicate mx behavior on ALL spark
> >skinnableComponents but keeping the current behavior as the default.
> >
> >
> >On 17 July 2014 11:14, DarkStone <da...@163.com> wrote:
> >
> >> Hi,
> >>
> >> MX (Halo) was discontinued long time ago.
> >>
> >> The 'enabled' implementation of the Spark SkinnableComponent is correct,
> >> no need to change, it's better this way, because developers can
> explicitly
> >> set the values of the mouseChildren and mouseEnabled for their
> >> CustomSkin.mxml.
> >>
> >> If you do want to change it, you can subclass the SkinnableComponent,
> and
> >> override the public function set enabled(value:Boolean):void to whatever
> >> you want it to be.
> >>
> >>
> >> DarkStone
> >> 2014-07-17
> >>
> >>
> >> At 2014-07-17 05:51:46, João Fernandes" <
> >> joaopedromartinsfernandes@gmail.com> wrote:
> >> >Hi, something that has bugging me is that skinnable components behave
> >> >differently from mx conter part when the object has enabled = false.
> >> >In MX all components still respond to mouseEvents while skinnable won't
> >> >because at the skinnableComponent level we have this
> >> >
> >> > override public function set enabled(value:Boolean):void
> >> > {
> >> > super.enabled = value;
> >> > invalidateSkinState();
> >> >
> >> > // If enabled, reset the mouseChildren, mouseEnabled to the
> >> >previously
> >> > // set explicit value, otherwise disable mouse interaction.
> >> > super.mouseChildren = value ? _explicitMouseChildren : false;
> >> > super.mouseEnabled = value ? _explicitMouseEnabled : false;
> >> > }
> >> >
> >> >I plan to implement a similar mx behavior but keeping the current
> behavior
> >> >as the default.
> >> >
> >> >Before I start doing anything, is there any reason for this difference
> in
> >> >behavior?
> >> >
> >> >--
> >> >
> >> >João Fernandes
> >>
> >
> >
> >
> >--
> >
> >João Fernandes
>
--
João Fernandes
Re:Re: Different behavior between mx and spark
Posted by DarkStone <da...@163.com>.
Hi,
>What I want to achieve is to replicate mx behavior on ALL spark
>skinnableComponents but keeping the current behavior as the default.
IMO, the mx behavior is worse than Spark, so I don't recommend to replicate mx behavior on ALL spark skinnableComponents, this is a very bad idea, and this will affect all the existing Flex Spark projects.
What you want to achieve is an edge case, not a common case, so I recommend you subclass the SkinableComponent (like MySkinableComponent), and override any behaviors you want, then make all of your custom components by subclass your MySkinableComponent.
DarkStone
2014-07-17
At 2014-07-17 06:37:37, "João Fernandes" <jo...@gmail.com> wrote:
>Sorry but setting mouseChildren and mouseEnabled won't work for their
>customSkin since skinnableComponent does check if the component is enabled
>and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
>an option in this case because it would require the entire spark components
>to be rewritten extending the new class and monkey patching isn't an option.
>
>What I want to achieve is to replicate mx behavior on ALL spark
>skinnableComponents but keeping the current behavior as the default.
>
>
>On 17 July 2014 11:14, DarkStone <da...@163.com> wrote:
>
>> Hi,
>>
>> MX (Halo) was discontinued long time ago.
>>
>> The 'enabled' implementation of the Spark SkinnableComponent is correct,
>> no need to change, it's better this way, because developers can explicitly
>> set the values of the mouseChildren and mouseEnabled for their
>> CustomSkin.mxml.
>>
>> If you do want to change it, you can subclass the SkinnableComponent, and
>> override the public function set enabled(value:Boolean):void to whatever
>> you want it to be.
>>
>>
>> DarkStone
>> 2014-07-17
>>
>>
>> At 2014-07-17 05:51:46, João Fernandes" <
>> joaopedromartinsfernandes@gmail.com> wrote:
>> >Hi, something that has bugging me is that skinnable components behave
>> >differently from mx conter part when the object has enabled = false.
>> >In MX all components still respond to mouseEvents while skinnable won't
>> >because at the skinnableComponent level we have this
>> >
>> > override public function set enabled(value:Boolean):void
>> > {
>> > super.enabled = value;
>> > invalidateSkinState();
>> >
>> > // If enabled, reset the mouseChildren, mouseEnabled to the
>> >previously
>> > // set explicit value, otherwise disable mouse interaction.
>> > super.mouseChildren = value ? _explicitMouseChildren : false;
>> > super.mouseEnabled = value ? _explicitMouseEnabled : false;
>> > }
>> >
>> >I plan to implement a similar mx behavior but keeping the current behavior
>> >as the default.
>> >
>> >Before I start doing anything, is there any reason for this difference in
>> >behavior?
>> >
>> >--
>> >
>> >João Fernandes
>>
>
>
>
>--
>
>João Fernandes
Re: Different behavior between mx and spark
Posted by João Fernandes <jo...@gmail.com>.
Sorry but setting mouseChildren and mouseEnabled won't work for their
customSkin since skinnableComponent does check if the component is enabled
and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
an option in this case because it would require the entire spark components
to be rewritten extending the new class and monkey patching isn't an option.
What I want to achieve is to replicate mx behavior on ALL spark
skinnableComponents but keeping the current behavior as the default.
On 17 July 2014 11:14, DarkStone <da...@163.com> wrote:
> Hi,
>
> MX (Halo) was discontinued long time ago.
>
> The 'enabled' implementation of the Spark SkinnableComponent is correct,
> no need to change, it's better this way, because developers can explicitly
> set the values of the mouseChildren and mouseEnabled for their
> CustomSkin.mxml.
>
> If you do want to change it, you can subclass the SkinnableComponent, and
> override the public function set enabled(value:Boolean):void to whatever
> you want it to be.
>
>
> DarkStone
> 2014-07-17
>
>
> At 2014-07-17 05:51:46, João Fernandes" <
> joaopedromartinsfernandes@gmail.com> wrote:
> >Hi, something that has bugging me is that skinnable components behave
> >differently from mx conter part when the object has enabled = false.
> >In MX all components still respond to mouseEvents while skinnable won't
> >because at the skinnableComponent level we have this
> >
> > override public function set enabled(value:Boolean):void
> > {
> > super.enabled = value;
> > invalidateSkinState();
> >
> > // If enabled, reset the mouseChildren, mouseEnabled to the
> >previously
> > // set explicit value, otherwise disable mouse interaction.
> > super.mouseChildren = value ? _explicitMouseChildren : false;
> > super.mouseEnabled = value ? _explicitMouseEnabled : false;
> > }
> >
> >I plan to implement a similar mx behavior but keeping the current behavior
> >as the default.
> >
> >Before I start doing anything, is there any reason for this difference in
> >behavior?
> >
> >--
> >
> >João Fernandes
>
--
João Fernandes
Re: Different behavior between mx and spark
Posted by João Fernandes <jo...@gmail.com>.
Sorry but setting mouseChildren and mouseEnabled won't work for their
customSkin since skinnableComponent does check if the component is enabled
and skip the call to super.mouseChildren/mouseEnabled. Subclassing is not
an option in this case because it would require the entire spark components
to be rewritten extending the new class and monkey patching isn't an option.
What I want to achieve is to replicate mx behavior on ALL spark
skinnableComponents but keeping the current behavior as the default.
On 17 July 2014 11:14, DarkStone <da...@163.com> wrote:
> Hi,
>
> MX (Halo) was discontinued long time ago.
>
> The 'enabled' implementation of the Spark SkinnableComponent is correct,
> no need to change, it's better this way, because developers can explicitly
> set the values of the mouseChildren and mouseEnabled for their
> CustomSkin.mxml.
>
> If you do want to change it, you can subclass the SkinnableComponent, and
> override the public function set enabled(value:Boolean):void to whatever
> you want it to be.
>
>
> DarkStone
> 2014-07-17
>
>
> At 2014-07-17 05:51:46, João Fernandes" <
> joaopedromartinsfernandes@gmail.com> wrote:
> >Hi, something that has bugging me is that skinnable components behave
> >differently from mx conter part when the object has enabled = false.
> >In MX all components still respond to mouseEvents while skinnable won't
> >because at the skinnableComponent level we have this
> >
> > override public function set enabled(value:Boolean):void
> > {
> > super.enabled = value;
> > invalidateSkinState();
> >
> > // If enabled, reset the mouseChildren, mouseEnabled to the
> >previously
> > // set explicit value, otherwise disable mouse interaction.
> > super.mouseChildren = value ? _explicitMouseChildren : false;
> > super.mouseEnabled = value ? _explicitMouseEnabled : false;
> > }
> >
> >I plan to implement a similar mx behavior but keeping the current behavior
> >as the default.
> >
> >Before I start doing anything, is there any reason for this difference in
> >behavior?
> >
> >--
> >
> >João Fernandes
>
--
João Fernandes
Re:Different behavior between mx and spark
Posted by DarkStone <da...@163.com>.
Hi,
MX (Halo) was discontinued long time ago.
The 'enabled' implementation of the Spark SkinnableComponent is correct, no need to change, it's better this way, because developers can explicitly set the values of the mouseChildren and mouseEnabled for their CustomSkin.mxml.
If you do want to change it, you can subclass the SkinnableComponent, and override the public function set enabled(value:Boolean):void to whatever you want it to be.
DarkStone
2014-07-17
At 2014-07-17 05:51:46, João Fernandes" <jo...@gmail.com> wrote:
>Hi, something that has bugging me is that skinnable components behave
>differently from mx conter part when the object has enabled = false.
>In MX all components still respond to mouseEvents while skinnable won't
>because at the skinnableComponent level we have this
>
> override public function set enabled(value:Boolean):void
> {
> super.enabled = value;
> invalidateSkinState();
>
> // If enabled, reset the mouseChildren, mouseEnabled to the
>previously
> // set explicit value, otherwise disable mouse interaction.
> super.mouseChildren = value ? _explicitMouseChildren : false;
> super.mouseEnabled = value ? _explicitMouseEnabled : false;
> }
>
>I plan to implement a similar mx behavior but keeping the current behavior
>as the default.
>
>Before I start doing anything, is there any reason for this difference in
>behavior?
>
>--
>
>João Fernandes