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" <joaopedromartinsfernan...@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 <darkst...@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" <
>> joaopedromartinsfernan...@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 <darkst...@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" <
>> >> joaopedromartinsfernan...@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
