Skip to main content
Known Participant
October 23, 2008
Question

partRemoved(), includeIn and adding a control to a displayList

  • October 23, 2008
  • 8 replies
  • 1286 views
Hi,

I'm having a strange behavior with some Gumbo components I developed. For these components I implemented skins and I'm handling the skin parts in the partAdded and the partRemoved functions.

In my application I'm showing one of different components (views) depending on a selection in a list. For this I'm creating the different views without adding them to a displayList (in a Declarations tag). When the selection changes, I replace the displayed view accordingly.

With components that use "includeIn" in their skins I'm getting null pointer exceptions in their partRemoved methods. I noticed that this happens with views I showed once and trying to show again, which means they were added to a displayList, removed then being added again. This seems to make their skin to be unloaded and reloaded.


First question: Is this the normal beahvior or a bug?

Now to the strange part: In the partRemoved method call, sometimes I get null for the instance parameter! I think this happens depending on the actual state of the component. If the skin part should be discarded from the actual state (using includeIn), it's passed as null! In the other hand, it seems that partRemoved is called more than once (probably for the different states?).


Second question: Is this normal behavior or a bug?
Third question: If this is normal, how should I handle these cases? Should I check instance if it's null?

I found nothing about this behavior in the specs.


Bye,

--
Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com



This topic has been closed for replies.

8 replies

Known Participant
October 24, 2008
Here it is: https://bugs.adobe.com/jira/browse/SDK-17750


On Fri, Oct 24, 2008 at 9:49 AM, Ryan Frishberg < member@adobeforums.com> wrote:

A new message was posted by Ryan Frishberg in



Developers --

  partRemoved(), includeIn and adding a control to a displayList



It'd help us out if you filed a bug. That way it gets officially tracked, there's a test case to make sure it's all working, and we can more easily add the testcase to our own suite of tests. Regardless, I'll fix it soon, but filing a bug would be much appreciated.





View/reply at partRemoved(), includeIn and adding a control to a displayList

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.





--
Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com



Participating Frequently
October 24, 2008
It'd help us out if you filed a bug. That way it gets officially tracked, there's a test case to make sure it's all working, and we can more easily add the testcase to our own suite of tests. Regardless, I'll fix it soon, but filing a bug would be much appreciated.
Known Participant
October 24, 2008
I don't need to file a bug anymore? I was about to do it.


On Fri, Oct 24, 2008 at 8:53 AM, Ryan Frishberg < member@adobeforums.com> wrote:

A new message was posted by Ryan Frishberg in



Developers --

  partRemoved(), includeIn and adding a control to a displayList



Yeah, you are right. We need to make sure to do null checks. I'll fix that up as well and check for other scenarios.





View/reply at partRemoved(), includeIn and adding a control to a displayList

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.





--
Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com



Participating Frequently
October 24, 2008
Yeah, you are right. We need to make sure to do null checks. I'll fix that up as well and check for other scenarios.
Known Participant
October 24, 2008
There are different places where partAdded and partRemoved are called. I think the important thing is to make sure, that partRemoved get really only called for skin parts for which partAdded has been called.


The code causing the errors in my case is in clearSkinParts(). In findSkinParts(), here is the code that calls partAdded:

// If the assigned part has already been instantiated, call partAdded() here,

// but only for static parts.
if (this[ part.id] != null && !(this[ part.id] is IFactory))

    partAdded( part.id, this[ part.id]);


But in clearSkinParts() the test for null is NOT done:

if (!(this[skinPartID] is IFactory))
{

    partRemoved(skinPartID, this[skinPartID]);
}


Your notes about skin_propertyChangeHandler() seem also to be right! Perhaps there are other places where similar tests must be done.


On Thu, Oct 23, 2008 at 10:24 PM, Ryan Frishberg < member@adobeforums.com> wrote:

A new message was posted by Ryan Frishberg in



Developers --

  partRemoved(), includeIn and adding a control to a displayList



So if I understand you correctly, I think what you've got is a bug. In skin_propertyChangeHandler, I think the proper thing to do is:

1. If there was a previous non-null skin part (that's not dynamic), call partRemoved on it.


2. If there is a new non-null skin part (that's not dynamic), call partAdded on it.

Right now we always just call partAdded().

If this sounds right, file a bug in JIRA, and we should fix it.


Were there any other issues here that needed discussion?





View/reply at partRemoved(), includeIn and adding a control to a displayList

Replies by email are OK.

Use the unsubscribe form to cancel your email subscription.





--
Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com



Participating Frequently
October 23, 2008
So if I understand you correctly, I think what you've got is a bug. In skin_propertyChangeHandler, I think the proper thing to do is:

1. If there was a previous non-null skin part (that's not dynamic), call partRemoved on it.
2. If there is a new non-null skin part (that's not dynamic), call partAdded on it.

Right now we always just call partAdded().

If this sounds right, file a bug in JIRA, and we should fix it.

Were there any other issues here that needed discussion?
Known Participant
October 23, 2008
More debugging results!
Just was wondering what happens in the partAdded method and I found out, the different parts are only created when the component enters in a state in which they are included. If this never happens in the life cycle of the component, these parts will never be created, that's why they are null when partRemoved is called.
This seems to be logical. Now the question is, should we test if instance is null in partRemoved or should Gumbo not call partRemoved for parts for which it didn't call partAdded?
I would vote for the second one, what's your opinion?
Known Participant
October 23, 2008
I added a breakpoint in the partRemoved method of one component having this problem to analyze the skin state and the values of the different parts. Here is the result:

Skin parts:
---
[SkinPart]
public var videoDisplay:VideoDisplay;

[SkinPart]
public var playButton:FxButton;

[SkinPart]
public var pauseButton:FxButton;

[SkinPart]
public var soundOnButton:FxButton;

[SkinPart]
public var soundOffButton:FxButton;

[SkinPart]
public var positionSlider:FxSlider;
---

Skin states:
---
[SkinStates("disabled", "playingSoundOn", "playingSoundOff", "pausedSoundOn", "pausedSoundOff")]
---

States definition in the skin:
---







---

Parts definition in the skin:
---












---

Values when partRemoved is called the first time:
---
partName: "soundOnButton"
instance: null
this.skin.currentState: "pausedSoundOn"
this.videoDisplay: mx.controls.VideoDisplay (@b193cf1)
this.playButton: mx.components.FxButton (@b25b6d1)
this.pauseButton: null
this.soundOnButton: null
this.soundOffButton: mx.components.FxButton (@b25b3c1)
this.positionSlider: mx.components.FxHSlider (@b2146d1)
---

Notice that this.pauseButton and this.soundOnButton are set to null and these are the parts that are not included in the "pausedSoundOn" state which is the actual state.

Shouldn't partRemoved be called once for EVERY part independently of the state?