You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by DarkStone <da...@163.com> on 2014/12/16 10:27:27 UTC
[4.13.0][FLEX-34689] SkinnableComponent change skin bug (Already
solved, awaiting review by others)
Hi,
I found a bug of SkinnableComponent, when use the styleName property to change the skin, in certain circumstances it does not work, the skin won't change!
I've already created the JIRA issue for this bug:
https://issues.apache.org/jira/browse/FLEX-34689
I've already figured it out how to fix this bug, it's very eazy to fix:
Just modify the source code of SkinnableComponent.as, and add the following code to the class:
override public function set styleName(value:Object):void
{
clearStyle("skinClass");
super.styleName = value;
}
This will solve this bug, and I've tested it in different scenarios, it works correctly!
I have trouble connecting to the Flex Git, the network right now is very crappy, may someone review this, if passed, may he commit this change to the Git, that will be very nice : - )
DarkStone
2014-12-16
Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug (Already solved, awaiting review by others)
Posted by Harbs <ha...@gmail.com>.
I’ve had trouble in the past. For some reason my Apache login got messed up. IIRC, resetting the password did it for me.
On Dec 17, 2014, at 1:07 PM, DarkStone <Da...@163.com> wrote:
> I have trouble connecting to the git, I don't know why
Re:Re: Re:Re: [4.13.0][FLEX-34689] SkinnableComponent change skin
bug (Already solved, awaiting review by others)
Posted by DarkStone <da...@163.com>.
Hi Erik,
I have trouble connecting to the git, I don't know why, I think I will use some VPN, then try to do this.
DarkStone
2014-12-17
At 2014-12-17 18:54:51, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>DarkStone,
>
>Why not commit the 2nd option for this fix to the 'develop' branch,
>and let Mustella run it's tests to see if nothing breaks? If someone
>objects, well, we "commit then review" and if someone vetoes the
>commit, we simply revert and have another look at the issue.
>
>Thanks,
>
>EdB
>
>
>
>On Wed, Dec 17, 2014 at 11:49 AM, DarkStone <da...@163.com> wrote:
>> Hi,
>>
>> I'm sorry, my bad, I missed a condition on that bug fix:
>>
>> This is wrong:
>> clearStyle("skinClass");
>>
>> This is correct:
>> styleProp == "styleName" ? clearStyle("skinClass") : null;
>>
>> But even with this change, there is still a bug if you do the followings:
>>
>> 1. Inside the constructor function of a SkinnableComponent subclass:
>> super();
>> setStyle("skinClass", SkinA);
>>
>> 2. In mxml, set the styleName="skinB" to that component.
>>
>> Run the application, SkinA shows, which is wrong, should be SkinB.
>>
>>
>> So, back to the start, right now, we still have to override the styleName setter function in SkinnableComponent.as
>>
>>
>> That is, if you add
>>
>> styleProp == "styleName" ? clearStyle("skinClass") : null;
>>
>> to the styleChanged() function (line 552) of SkinnableComponent.as, there is still a bug I described above.
>>
>>
>>
>> Or, if you just add
>>
>> override public function set styleName(value:Object):void
>> {
>> clearStyle("skinClass");
>> super.styleName = value;
>> }
>>
>> to SkinnableComponent.as, it will solve these bugs.
>>
>> I still prefer to the second one.
>>
>>
>> DarkStone
>> 2014-12-17
>>
>>
>> At 2014-12-17 18:05:43, "DarkStone" <da...@163.com> wrote:
>>>Hi Alex,
>>>
>>>I've located the problem:
>>>
>>>Step 1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an initial skin is ok.
>>>
>>>Step 2. Then using MySkinnableComponent.styleName = "skinB" won't work, the skin won't change.
>>>
>>>When [Step 2] happens, inside the validateSkinChange() function of SkinnableComponent.as (line 440-443):
>>>
>>>newSkinClass = getStyle("skinClass");
>>>skipReload = newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin);
>>>
>>>The getStyle("skinClass") returns the old skin (SkinA), which should be the new skin (SkinB).
>>>
>>>As a result, the newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin) returns true, which should be false.
>>>
>>>That's why the SkinnableComponent won't change the skin.
>>>
>>>
>>>
>>>I know how to fix this now.
>>>
>>>No need to override the styleName setter function in SkinnableComponent.as.
>>>
>>>Just add a line clearStyle("skinClass") to styleChanged() function in SkinnableComponent.as (add at line 552):
>>>
>>>override public function styleChanged(styleProp:String):void
>>>{
>>> var allStyles:Boolean = styleProp == null || styleProp == "styleName";
>>>
>>> if (allStyles || styleProp == "skinClass" || styleProp == "skinFactory")
>>> {
>>> clearStyle("skinClass"); //This will fix the bug
>>> skinChanged = true;
>>> invalidateProperties();
>>>
>>> if (styleProp == "skinFactory")
>>> skinFactoryStyleChanged = true;
>>> }
>>>
>>> super.styleChanged(styleProp);
>>>}
>>>
>>>clearStyle("skinClass"); //This will fix the bug
>>>That's the only line needs to be added, in order to fix this bug.
>>>
>>>
>>>I've already updated the JIRA for this
>>>https://issues.apache.org/jira/browse/FLEX-34689
>>>
>>>
>>>DarkStone
>>>2014-12-17
>>>
>>>
>>>在 2014-12-17 14:12:52，"Alex Harui" <ah...@adobe.com> 写道：
>>>>
>>>>
>>>>On 12/16/14, 9:36 PM, "DarkStone" <Da...@163.com> wrote:
>>>>
>>>>>Hi Alex,
>>>>>
>>>>>Why this needs to be fixed is simple:
>>>>>
>>>>>1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an
>>>>>initial skin is ok.
>>>>>
>>>>>2. Then using MySkinnableComponent.styleName = "skinB" won't work, the
>>>>>skin won't change.
>>>>>
>>>>>The styleChanged() function in SkinnableComponent doesn't handle this
>>>>>scenario correctly, that's why we need to override the styleName setter
>>>>>function to fix this.
>>>>
>>>>I’m wondering why the styleChanged() function can’t be changed to handle
>>>>this scenario correctly. There are other ways to change skinClass, like
>>>>setting it directly in a CSSStyleDeclaration or by loading a Style module.
>>>> I would expect them all to call styleChanged() and the right thing to
>>>>happen.
>>>>
>>>>Thanks,
>>>>-Alex
>>>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: Re: Re:Re: [4.13.0][FLEX-34689] SkinnableComponent change skin
bug (Already solved, awaiting review by others)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>>Why not commit the 2nd option for this fix to the 'develop' branch, ...
>
> I've done the change (the 2nd option), and pushed it to the 'develop' branch.
>
> Awaiting review and vote.
I'll let Mustella have a go at the new code first. I'm sure some other
committers will have an opinion as well.
There is no vote needed. All that may happen is that someone vetoes
the commit, but we'll deal with that if and when that happens.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re:Re: Re:Re: [4.13.0][FLEX-34689] SkinnableComponent change skin
bug (Already solved, awaiting review by others)
Posted by DarkStone <da...@163.com>.
Hi Erik,
>Why not commit the 2nd option for this fix to the 'develop' branch, ...
I've done the change (the 2nd option), and pushed it to the 'develop' branch.
Awaiting review and vote.
DarkStone
2014-12-18
At 2014-12-17 18:54:51, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>DarkStone,
>
>Why not commit the 2nd option for this fix to the 'develop' branch,
>and let Mustella run it's tests to see if nothing breaks? If someone
>objects, well, we "commit then review" and if someone vetoes the
>commit, we simply revert and have another look at the issue.
>
>Thanks,
>
>EdB
>
>
>
>On Wed, Dec 17, 2014 at 11:49 AM, DarkStone <da...@163.com> wrote:
>> Hi,
>>
>> I'm sorry, my bad, I missed a condition on that bug fix:
>>
>> This is wrong:
>> clearStyle("skinClass");
>>
>> This is correct:
>> styleProp == "styleName" ? clearStyle("skinClass") : null;
>>
>> But even with this change, there is still a bug if you do the followings:
>>
>> 1. Inside the constructor function of a SkinnableComponent subclass:
>> super();
>> setStyle("skinClass", SkinA);
>>
>> 2. In mxml, set the styleName="skinB" to that component.
>>
>> Run the application, SkinA shows, which is wrong, should be SkinB.
>>
>>
>> So, back to the start, right now, we still have to override the styleName setter function in SkinnableComponent.as
>>
>>
>> That is, if you add
>>
>> styleProp == "styleName" ? clearStyle("skinClass") : null;
>>
>> to the styleChanged() function (line 552) of SkinnableComponent.as, there is still a bug I described above.
>>
>>
>>
>> Or, if you just add
>>
>> override public function set styleName(value:Object):void
>> {
>> clearStyle("skinClass");
>> super.styleName = value;
>> }
>>
>> to SkinnableComponent.as, it will solve these bugs.
>>
>> I still prefer to the second one.
>>
>>
>> DarkStone
>> 2014-12-17
>>
>>
>> At 2014-12-17 18:05:43, "DarkStone" <da...@163.com> wrote:
>>>Hi Alex,
>>>
>>>I've located the problem:
>>>
>>>Step 1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an initial skin is ok.
>>>
>>>Step 2. Then using MySkinnableComponent.styleName = "skinB" won't work, the skin won't change.
>>>
>>>When [Step 2] happens, inside the validateSkinChange() function of SkinnableComponent.as (line 440-443):
>>>
>>>newSkinClass = getStyle("skinClass");
>>>skipReload = newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin);
>>>
>>>The getStyle("skinClass") returns the old skin (SkinA), which should be the new skin (SkinB).
>>>
>>>As a result, the newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin) returns true, which should be false.
>>>
>>>That's why the SkinnableComponent won't change the skin.
>>>
>>>
>>>
>>>I know how to fix this now.
>>>
>>>No need to override the styleName setter function in SkinnableComponent.as.
>>>
>>>Just add a line clearStyle("skinClass") to styleChanged() function in SkinnableComponent.as (add at line 552):
>>>
>>>override public function styleChanged(styleProp:String):void
>>>{
>>> var allStyles:Boolean = styleProp == null || styleProp == "styleName";
>>>
>>> if (allStyles || styleProp == "skinClass" || styleProp == "skinFactory")
>>> {
>>> clearStyle("skinClass"); //This will fix the bug
>>> skinChanged = true;
>>> invalidateProperties();
>>>
>>> if (styleProp == "skinFactory")
>>> skinFactoryStyleChanged = true;
>>> }
>>>
>>> super.styleChanged(styleProp);
>>>}
>>>
>>>clearStyle("skinClass"); //This will fix the bug
>>>That's the only line needs to be added, in order to fix this bug.
>>>
>>>
>>>I've already updated the JIRA for this
>>>https://issues.apache.org/jira/browse/FLEX-34689
>>>
>>>
>>>DarkStone
>>>2014-12-17
>>>
>>>
>>>在 2014-12-17 14:12:52，"Alex Harui" <ah...@adobe.com> 写道：
>>>>
>>>>
>>>>On 12/16/14, 9:36 PM, "DarkStone" <Da...@163.com> wrote:
>>>>
>>>>>Hi Alex,
>>>>>
>>>>>Why this needs to be fixed is simple:
>>>>>
>>>>>1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an
>>>>>initial skin is ok.
>>>>>
>>>>>2. Then using MySkinnableComponent.styleName = "skinB" won't work, the
>>>>>skin won't change.
>>>>>
>>>>>The styleChanged() function in SkinnableComponent doesn't handle this
>>>>>scenario correctly, that's why we need to override the styleName setter
>>>>>function to fix this.
>>>>
>>>>I’m wondering why the styleChanged() function can’t be changed to handle
>>>>this scenario correctly. There are other ways to change skinClass, like
>>>>setting it directly in a CSSStyleDeclaration or by loading a Style module.
>>>> I would expect them all to call styleChanged() and the right thing to
>>>>happen.
>>>>
>>>>Thanks,
>>>>-Alex
>>>>
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
Re: Re:Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug
(Already solved, awaiting review by others)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
DarkStone,
Why not commit the 2nd option for this fix to the 'develop' branch,
and let Mustella run it's tests to see if nothing breaks? If someone
objects, well, we "commit then review" and if someone vetoes the
commit, we simply revert and have another look at the issue.
Thanks,
EdB
On Wed, Dec 17, 2014 at 11:49 AM, DarkStone <da...@163.com> wrote:
> Hi,
>
> I'm sorry, my bad, I missed a condition on that bug fix:
>
> This is wrong:
> clearStyle("skinClass");
>
> This is correct:
> styleProp == "styleName" ? clearStyle("skinClass") : null;
>
> But even with this change, there is still a bug if you do the followings:
>
> 1. Inside the constructor function of a SkinnableComponent subclass:
> super();
> setStyle("skinClass", SkinA);
>
> 2. In mxml, set the styleName="skinB" to that component.
>
> Run the application, SkinA shows, which is wrong, should be SkinB.
>
>
> So, back to the start, right now, we still have to override the styleName setter function in SkinnableComponent.as
>
>
> That is, if you add
>
> styleProp == "styleName" ? clearStyle("skinClass") : null;
>
> to the styleChanged() function (line 552) of SkinnableComponent.as, there is still a bug I described above.
>
>
>
> Or, if you just add
>
> override public function set styleName(value:Object):void
> {
> clearStyle("skinClass");
> super.styleName = value;
> }
>
> to SkinnableComponent.as, it will solve these bugs.
>
> I still prefer to the second one.
>
>
> DarkStone
> 2014-12-17
>
>
> At 2014-12-17 18:05:43, "DarkStone" <da...@163.com> wrote:
>>Hi Alex,
>>
>>I've located the problem:
>>
>>Step 1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an initial skin is ok.
>>
>>Step 2. Then using MySkinnableComponent.styleName = "skinB" won't work, the skin won't change.
>>
>>When [Step 2] happens, inside the validateSkinChange() function of SkinnableComponent.as (line 440-443):
>>
>>newSkinClass = getStyle("skinClass");
>>skipReload = newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin);
>>
>>The getStyle("skinClass") returns the old skin (SkinA), which should be the new skin (SkinB).
>>
>>As a result, the newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin) returns true, which should be false.
>>
>>That's why the SkinnableComponent won't change the skin.
>>
>>
>>
>>I know how to fix this now.
>>
>>No need to override the styleName setter function in SkinnableComponent.as.
>>
>>Just add a line clearStyle("skinClass") to styleChanged() function in SkinnableComponent.as (add at line 552):
>>
>>override public function styleChanged(styleProp:String):void
>>{
>> var allStyles:Boolean = styleProp == null || styleProp == "styleName";
>>
>> if (allStyles || styleProp == "skinClass" || styleProp == "skinFactory")
>> {
>> clearStyle("skinClass"); //This will fix the bug
>> skinChanged = true;
>> invalidateProperties();
>>
>> if (styleProp == "skinFactory")
>> skinFactoryStyleChanged = true;
>> }
>>
>> super.styleChanged(styleProp);
>>}
>>
>>clearStyle("skinClass"); //This will fix the bug
>>That's the only line needs to be added, in order to fix this bug.
>>
>>
>>I've already updated the JIRA for this
>>https://issues.apache.org/jira/browse/FLEX-34689
>>
>>
>>DarkStone
>>2014-12-17
>>
>>
>>在 2014-12-17 14:12:52，"Alex Harui" <ah...@adobe.com> 写道：
>>>
>>>
>>>On 12/16/14, 9:36 PM, "DarkStone" <Da...@163.com> wrote:
>>>
>>>>Hi Alex,
>>>>
>>>>Why this needs to be fixed is simple:
>>>>
>>>>1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an
>>>>initial skin is ok.
>>>>
>>>>2. Then using MySkinnableComponent.styleName = "skinB" won't work, the
>>>>skin won't change.
>>>>
>>>>The styleChanged() function in SkinnableComponent doesn't handle this
>>>>scenario correctly, that's why we need to override the styleName setter
>>>>function to fix this.
>>>
>>>I’m wondering why the styleChanged() function can’t be changed to handle
>>>this scenario correctly. There are other ways to change skinClass, like
>>>setting it directly in a CSSStyleDeclaration or by loading a Style module.
>>> I would expect them all to call styleChanged() and the right thing to
>>>happen.
>>>
>>>Thanks,
>>>-Alex
>>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re:Re:Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug
(Already solved, awaiting review by others)
Posted by DarkStone <da...@163.com>.
Hi,
I'm sorry, my bad, I missed a condition on that bug fix:
This is wrong:
clearStyle("skinClass");
This is correct:
styleProp == "styleName" ? clearStyle("skinClass") : null;
But even with this change, there is still a bug if you do the followings:
1. Inside the constructor function of a SkinnableComponent subclass:
super();
setStyle("skinClass", SkinA);
2. In mxml, set the styleName="skinB" to that component.
Run the application, SkinA shows, which is wrong, should be SkinB.
So, back to the start, right now, we still have to override the styleName setter function in SkinnableComponent.as
That is, if you add
styleProp == "styleName" ? clearStyle("skinClass") : null;
to the styleChanged() function (line 552) of SkinnableComponent.as, there is still a bug I described above.
Or, if you just add
override public function set styleName(value:Object):void
{
clearStyle("skinClass");
super.styleName = value;
}
to SkinnableComponent.as, it will solve these bugs.
I still prefer to the second one.
DarkStone
2014-12-17
At 2014-12-17 18:05:43, "DarkStone" <da...@163.com> wrote:
>Hi Alex,
>
>I've located the problem:
>
>Step 1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an initial skin is ok.
>
>Step 2. Then using MySkinnableComponent.styleName = "skinB" won't work, the skin won't change.
>
>When [Step 2] happens, inside the validateSkinChange() function of SkinnableComponent.as (line 440-443):
>
>newSkinClass = getStyle("skinClass");
>skipReload = newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin);
>
>The getStyle("skinClass") returns the old skin (SkinA), which should be the new skin (SkinB).
>
>As a result, the newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin) returns true, which should be false.
>
>That's why the SkinnableComponent won't change the skin.
>
>
>
>I know how to fix this now.
>
>No need to override the styleName setter function in SkinnableComponent.as.
>
>Just add a line clearStyle("skinClass") to styleChanged() function in SkinnableComponent.as (add at line 552):
>
>override public function styleChanged(styleProp:String):void
>{
> var allStyles:Boolean = styleProp == null || styleProp == "styleName";
>
> if (allStyles || styleProp == "skinClass" || styleProp == "skinFactory")
> {
> clearStyle("skinClass"); //This will fix the bug
> skinChanged = true;
> invalidateProperties();
>
> if (styleProp == "skinFactory")
> skinFactoryStyleChanged = true;
> }
>
> super.styleChanged(styleProp);
>}
>
>clearStyle("skinClass"); //This will fix the bug
>That's the only line needs to be added, in order to fix this bug.
>
>
>I've already updated the JIRA for this
>https://issues.apache.org/jira/browse/FLEX-34689
>
>
>DarkStone
>2014-12-17
>
>
>在 2014-12-17 14:12:52，"Alex Harui" <ah...@adobe.com> 写道：
>>
>>
>>On 12/16/14, 9:36 PM, "DarkStone" <Da...@163.com> wrote:
>>
>>>Hi Alex,
>>>
>>>Why this needs to be fixed is simple:
>>>
>>>1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an
>>>initial skin is ok.
>>>
>>>2. Then using MySkinnableComponent.styleName = "skinB" won't work, the
>>>skin won't change.
>>>
>>>The styleChanged() function in SkinnableComponent doesn't handle this
>>>scenario correctly, that's why we need to override the styleName setter
>>>function to fix this.
>>
>>I’m wondering why the styleChanged() function can’t be changed to handle
>>this scenario correctly. There are other ways to change skinClass, like
>>setting it directly in a CSSStyleDeclaration or by loading a Style module.
>> I would expect them all to call styleChanged() and the right thing to
>>happen.
>>
>>Thanks,
>>-Alex
>>
Re:Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug
(Already solved, awaiting review by others)
Posted by DarkStone <da...@163.com>.
Hi Alex,
I've located the problem:
Step 1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an initial skin is ok.
Step 2. Then using MySkinnableComponent.styleName = "skinB" won't work, the skin won't change.
When [Step 2] happens, inside the validateSkinChange() function of SkinnableComponent.as (line 440-443):
newSkinClass = getStyle("skinClass");
skipReload = newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin);
The getStyle("skinClass") returns the old skin (SkinA), which should be the new skin (SkinB).
As a result, the newSkinClass && getQualifiedClassName(newSkinClass) == getQualifiedClassName(_skin) returns true, which should be false.
That's why the SkinnableComponent won't change the skin.
I know how to fix this now.
No need to override the styleName setter function in SkinnableComponent.as.
Just add a line clearStyle("skinClass") to styleChanged() function in SkinnableComponent.as (add at line 552):
override public function styleChanged(styleProp:String):void
{
var allStyles:Boolean = styleProp == null || styleProp == "styleName";
if (allStyles || styleProp == "skinClass" || styleProp == "skinFactory")
{
clearStyle("skinClass"); //This will fix the bug
skinChanged = true;
invalidateProperties();
if (styleProp == "skinFactory")
skinFactoryStyleChanged = true;
}
super.styleChanged(styleProp);
}
clearStyle("skinClass"); //This will fix the bug
That's the only line needs to be added, in order to fix this bug.
I've already updated the JIRA for this
https://issues.apache.org/jira/browse/FLEX-34689
DarkStone
2014-12-17
在 2014-12-17 14:12:52，"Alex Harui" <ah...@adobe.com> 写道：
>
>
>On 12/16/14, 9:36 PM, "DarkStone" <Da...@163.com> wrote:
>
>>Hi Alex,
>>
>>Why this needs to be fixed is simple:
>>
>>1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an
>>initial skin is ok.
>>
>>2. Then using MySkinnableComponent.styleName = "skinB" won't work, the
>>skin won't change.
>>
>>The styleChanged() function in SkinnableComponent doesn't handle this
>>scenario correctly, that's why we need to override the styleName setter
>>function to fix this.
>
>I’m wondering why the styleChanged() function can’t be changed to handle
>this scenario correctly. There are other ways to change skinClass, like
>setting it directly in a CSSStyleDeclaration or by loading a Style module.
> I would expect them all to call styleChanged() and the right thing to
>happen.
>
>Thanks,
>-Alex
>
Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug (Already
solved, awaiting review by others)
Posted by Alex Harui <ah...@adobe.com>.
On 12/16/14, 9:36 PM, "DarkStone" <Da...@163.com> wrote:
>Hi Alex,
>
>Why this needs to be fixed is simple:
>
>1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an
>initial skin is ok.
>
>2. Then using MySkinnableComponent.styleName = "skinB" won't work, the
>skin won't change.
>
>The styleChanged() function in SkinnableComponent doesn't handle this
>scenario correctly, that's why we need to override the styleName setter
>function to fix this.
I’m wondering why the styleChanged() function can’t be changed to handle
this scenario correctly. There are other ways to change skinClass, like
setting it directly in a CSSStyleDeclaration or by loading a Style module.
I would expect them all to call styleChanged() and the right thing to
happen.
Thanks,
-Alex
Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug (Already solved, awaiting review by others)
Posted by DarkStone <Da...@163.com>.
Hi Alex,
Why this needs to be fixed is simple:
1. Using MySkinnableComponent.setStyle("skinClass", SkinA) to apply an initial skin is ok.
2. Then using MySkinnableComponent.styleName = "skinB" won't work, the skin won't change.
The styleChanged() function in SkinnableComponent doesn't handle this scenario correctly, that's why we need to override the styleName setter function to fix this.
Sent from DarkStone's iPhone
2014-12-17
> 在 2014年12月17日，0:19，Alex Harui <ah...@adobe.com> 写道：
>
> Hi Darkstone,
>
> Can you provide more details on why this change is needed? In theory, the
> SkinnableComponent.styleChanged() method should have seen the styleName
> change.
>
> -Alex
>
>> On 12/16/14, 1:27 AM, "DarkStone" <da...@163.com> wrote:
>>
>> Hi,
>>
>> I found a bug of SkinnableComponent, when use the styleName property to
>> change the skin, in certain circumstances it does not work, the skin
>> won't change!
>>
>> I've already created the JIRA issue for this bug:
>> https://issues.apache.org/jira/browse/FLEX-34689
>>
>> I've already figured it out how to fix this bug, it's very eazy to fix:
>>
>> Just modify the source code of SkinnableComponent.as, and add the
>> following code to the class:
>>
>> override public function set styleName(value:Object):void
>> {
>> clearStyle("skinClass");
>> super.styleName = value;
>> }
>>
>> This will solve this bug, and I've tested it in different scenarios, it
>> works correctly!
>>
>> I have trouble connecting to the Flex Git, the network right now is very
>> crappy, may someone review this, if passed, may he commit this change to
>> the Git, that will be very nice : - )
>>
>>
>> DarkStone
>> 2014-12-16
>
Re: [4.13.0][FLEX-34689] SkinnableComponent change skin bug (Already
solved, awaiting review by others)
Posted by Alex Harui <ah...@adobe.com>.
Hi Darkstone,
Can you provide more details on why this change is needed? In theory, the
SkinnableComponent.styleChanged() method should have seen the styleName
change.
-Alex
On 12/16/14, 1:27 AM, "DarkStone" <da...@163.com> wrote:
>Hi,
>
>I found a bug of SkinnableComponent, when use the styleName property to
>change the skin, in certain circumstances it does not work, the skin
>won't change!
>
>I've already created the JIRA issue for this bug:
>https://issues.apache.org/jira/browse/FLEX-34689
>
>I've already figured it out how to fix this bug, it's very eazy to fix:
>
>Just modify the source code of SkinnableComponent.as, and add the
>following code to the class:
>
>override public function set styleName(value:Object):void
>{
> clearStyle("skinClass");
> super.styleName = value;
>}
>
>This will solve this bug, and I've tested it in different scenarios, it
>works correctly!
>
>I have trouble connecting to the Flex Git, the network right now is very
>crappy, may someone review this, if passed, may he commit this change to
>the Git, that will be very nice : - )
>
>
>DarkStone
>2014-12-16