Rank 1
Solution: Telerik should be cleaning up these objects on the on RemoveFromParent() API of the RadPane / RadGroup.
Workaround: On the RadDocking.Close Event, perform some function similar to the following:
| void ClearEmptyContainers() |
| { |
| for (int i = DockManager.Items.Count; i > 0; i--) |
| { |
| object item = DockManager.Items[i - 1]; |
| if (item is RadSplitContainer) |
| { |
| RadSplitContainer container = (RadSplitContainer)item; |
| if (container.Items.Count == 0) |
| { |
| DockManager.Items.Remove(container); |
| } |
| else |
| { |
| //Check for empty groups |
| for (int j = container.Items.Count; j > 0; j--) |
| { |
| RadPaneGroup group = container.Items[j - 1] as RadPaneGroup; |
| if (group.Items.Count == 0) |
| { |
| group.RemoveFromParent(); |
| DockManager.Items.Remove(container); |
| } |
| } |
| } |
| } |
| } |
| } |
9 Answers, 1 is accepted
Thank you for reporting us this issue! The reason why we are not cleaning these elements is that we are not persisting that they are auto-generated and we should do so. I logged the problem and we will fix it for one of the upcoming releases. The title of the item is "Docking control doesn't persis is the element autogenerated or when saving the layout.".
Your Telerik points were updated.
Kind regards,Miroslav Nedyalkov
the Telerik team
Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items.
Rank 1
I am having the same problem, PaneGroups and SplitContainers are not being cleaned up once all RadPanes are removed, causing over time the output of SaveLayout to be enormous.
Can I assume this one is not high on your priority list?
I will try the OP's work around but ideally RadDock should do a better job of cleaning up after itself.
Kind regards,
James.
Thank you for contacting us.
This problem will be resolved in our Q2 Service Pack 2 release coming soon.
Please do not hesitate to contact us if you require any further information.
Regards,George
the Telerik team
Rank 1
Hi
I'm trying to clean up dynamically created RadPane by executing its RemoveFromParent() method. RadPane seems to be closed correctly but in my case it has large amount of content. I tried to write Content = null; but the application memory was not decreased - the content still stays in the memory. Maybe RadPane still holds references to it and it prevents Garbage Collector to release it.
Do you have any idea?
Does Q2 Service Pack 2 contain smth to resolve this issue?
That is the right way to dispose the RadPane. But, please double check that this RadPane has no references. Otherwise It won't go to the garbage collector.
The Q2 Service Pack 2 contains a fix for the Save/Load of RadDocking layout. It has nothing to do with memory leaks.
Please do not hesitate to contact us if you require any further information.
Best wishes,George
the Telerik team
Rank 1
This appears to now be resolved, though I did notice something unusual while testing the SP2 fix..
Auto-generated empty SplitContainers and PaneGroups are only removed from the generated layout after they have been through a fresh LoadLayout/SaveLayout cycle, which may be caused by the fact there are still references to the SplitContainer/PaneGroup that are only disposed of after completing a SaveLayout then a fresh LoadLayout. Regardless, it caused me to initially believe the fix had not been applied correctly in SP2, but that is not the case.
So to reiterate, if I close a RadPane that leaves behind an empty auto generated SplitContainer/PaneGroup, then do SaveLayout, this empty SplitContainer/PaneGroup is still generated from SaveLayout (with attached IsAutoGenerated=True to each).
If I then do a LoadLayout of the previously persisted layout, then another SaveLayout, the SplitContainer/PaneGroup are not generated, which is the expected behaviour.
James
When a RadPane leaves behind an empty autogenerated RadPaneGroup and RadSplitContainer, these empty autogenerated RadPaneGroup/RadSplitContainer are destroyed if they don't keep any reference and they no longer exist. When you save the RadDocking control, these RadPaneGroup/RadSplitContainer won't be saved in the xml file because they don't exist. This is how the RadDocking control works. If something different happens, it could be a bug. Could you please explain in details what you do in order to accomplish the scenario you explained. Also, if you send us a demo and/or running project that reproduces the problem it would be very helpful. I will be glad to assist you further.
Looking forward to your reply.
George
the Telerik team
Rank 1
Here is the project again for the benefit of others, so they can easily replicate the issue described above (you will need to add in references to SP2 dll's).
http://cid-47007997392d2bb4.office.live.com/self.aspx/.Public/RadDockingCleanUpIssue20101014.zip
Kind regards,
James.
Thank you for reminding me this. I will need some time to take a deep look at the problem. I will inform you when I have any further information.
George
the Telerik team