#9778 closed defect (fixed)
AccordionContainer: incorrectly destroyed in ContentPane
Reported by: | vovasty | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.4 |
Component: | Dijit | Version: | 1.3.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
it overrides destroy() function with destroying buttons, but also should override destroyRecursive()
in some cases destroyRecursive() called before destroy() (for example, when accordion container is inside ContentPane, and we will set new content for ContentPane, it will call destroyRecursive(), and after it destroy())
destroyRecursive: function(){ dojo.forEach(this.getChildren(), function(child){ child._buttonWidget.destroy(); }); this.inherited(arguments); }
Attachments (1)
Change History (8)
comment:1 Changed 12 years ago by
Changed 12 years ago by
Attachment: | test_AccordionContainerDestroy.html added |
---|
comment:2 Changed 12 years ago by
place test under dijit/tests/layout/
ContentPane? calls destroyRecursive() BEFORE destroy(), it will destroy all children of accordeon (eg, child ContentPane?), after it will be called destroy() - but all ContentPanes? gone, and buttons will remains
comment:3 Changed 12 years ago by
Milestone: | tbd → 1.4 |
---|---|
Owner: | set to bill |
Status: | new → assigned |
Thanks for the test case!
OK, I see, AccordionContainer.destroy() code runs but it has no effect since getChildren() returns [].
comment:4 Changed 12 years ago by
Description: | modified (diff) |
---|---|
Summary: | AccordeonContainer incorrectly destroyed in ContentPane → AccordionContainer: incorrectly destroyed in ContentPane |
(Just fixing spelling so future searches can find this ticket.)
comment:5 Changed 12 years ago by
Seems like the root issue is that AccordionContainer.destroyDescendants(), and for that matter TabContainer.destroyDescendants(), don't clean up the buttons. This will be easier in 2.0 once #5796 is implemented but in the meantime I'll fixe the code, probably in StackContainer.js.
comment:6 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 12 years ago by
(In [19970]) TabContainer? fixes:
- Make children of TabContainer? w/doLayout=false get laid out properly (but not resized to fit TabContainer?).
- Make sure ScrollingTabController?.resize() is called (to layout arrow buttons etc) even when doLayout=false (fixes #9004)
- Convert pane2button[] and pane2handles[] key to be pane id (a string) instead of pane itself (an Object). The pane itself seemed to be causing lookup problems on IE6 in the test_TabContainer_noLayout.html test.
- also a fix related to destroyDescendants() for TabContainer? to prevent double-destroy of tab buttons (refs #9778)
!strict
What you mean by "it" -- AccordionContainer or ContentPane?
Anyway, destroyRecursive() calls destroy() so I don't see a reason to override destroyRecursive(). Can you attach a test case showing the problem?