Hi, I had posted this in the FlashBuilder forum but someone very kindly suggested I post it here instead. So that's what I'm doing.
I'm using FlashBuilder4 (set to Flex 3.5SDK for compatibility) and am running into an issue with RemoveChild/AddChild.
I have a TabNavigator component with several tabs, each tab utilizing a canvas as its child component.
What I'd like to do is to be able to click a button and have one of the tabs, say the first (index 0) inaccessbile, then to make it accessible upon clicking another button. My first thought was to disable the canvas for the first tab, but I don't see a property for that (i.e. no tabnavigator1.getChildAt(0).enabled property). But I DO see a "visible" property; unfortunately, doing a "tabnavigator1.getChildAt(0).visible = false" in the button's click handler doesn't seem to work. So I settled on removeChild. Clicking the first button calls a handler with "tabnavigator1.removeChild(canvas0)", where canvas0 is the child of the first tab, works fine. Unfortunately, to restore the child I use, in the clickhandler of the SECOND button, "tabnavigator1.addChildAt(canvas0,0);tabnavigator1.selectedIndex = 0" and this does cause the first tab to be selected BUT THE CONTENTS OF THE PREVIOUSLY DISPLAYED TAB OVERWRITE CANVAS0 (sorry for shouting, just wanted to emphasize).
The above seems to be an issue (for me at least) with addChild, since when I started playing with the new way FlashBuilder handles states, using Add/Remove Child, I would see the same type of behavior; i.e. one tab's contents overwriting another's.
Has anyone run into this issue (I've searched and don't see anything)? Failing that, any ideas what might be going on and what to do to correct/workaround this issue?
not sure if it will fix your problem but you can enable/disable Canvas.
instead of this:
tabnavigator1.getChildAt(0).enabled = false;
(tabnavigator1.getChildAt(0) as Canvas).enabled = false;
(FB doesnt know what kind of object getChildAt(0) is, so you have to help it out by specifying the type)
Well that certainly makes sense and is definitely worth a try, although I wonder why Flex itself doesn't realize this when it creates the code for various states. This issue definitely crops up when simply using the UI to create those states.
Thanks for the post. I'll let you know what happens.