empty form not disposing?
bobenjamins
Posts: 3
Hi,
I've tried the memory profiler and am having trouble understand the output completely.
To make it easier for me i created a fresh .net app with a mdi form opening a basic blank form.
when i ran the profiler i found un-disposed instances of the blank form still in memory (from just opening the form from a menu and closing).
i did this by taking a snapshot while the mdi was running, then again after i had opened and closed the form.
the code on the mdi menu is:
Dim frm As New Baby
frm.MdiParent = Me
frm.Show()
Could it be that the frm would be disposed of eventually? Currently it seems that it stays in memory forever. within the redgate memory profiler when i choose the tickbox to display those diposed objects which are still in memory - it still displays the instance of the Baby form.
how is this possible?
the baby form contains nothing:
Public Class Baby
inherits form
End Class
I've tried the memory profiler and am having trouble understand the output completely.
To make it easier for me i created a fresh .net app with a mdi form opening a basic blank form.
when i ran the profiler i found un-disposed instances of the blank form still in memory (from just opening the form from a menu and closing).
i did this by taking a snapshot while the mdi was running, then again after i had opened and closed the form.
the code on the mdi menu is:
Dim frm As New Baby
frm.MdiParent = Me
frm.Show()
Could it be that the frm would be disposed of eventually? Currently it seems that it stays in memory forever. within the redgate memory profiler when i choose the tickbox to display those diposed objects which are still in memory - it still displays the instance of the Baby form.
how is this possible?
the baby form contains nothing:
Public Class Baby
inherits form
End Class
Comments
I couldn't say why there is still a reference to the form -- it must be held from the parent form. Unfortunately I've never written any MDI forms.
You can use the Object Retention Graph for the form object to work out where the reference is being held. First, highlight the class, then click "Instance List" and then on the object retention graph symbol. The graph will point out the reference chain for that object.
Yes I used the graphs but stripped everything down to a basic mdi example to highlight that it indicated that memory was still not released.
The only way i am able to get the mdi to release the references once the child form is closed is to set the frm.MdiParent = nothing.
which effectively stops the child from being held within the mdi.
Your product is excellent and I would like to use it within our real app, but hesitate given that i can't seem to get results during this basic mdi app.
Basic in that all i've done is created a new mdi form and added a menu item with the call to open a blank child form.
I'm not sure if this is a problem with red gate (probably not) or if windows mdi forms just don't release references.
Chris.
* but take 10,000 times the memory!
Did you manage to get a solution to this MDI problem. I'd be very interested to know your solution.
Can you reply either way, so I know i can eliminate this topic for a potnetial solution.
Thanks in advance,
Stuart
Well reassuringly it seems there is a bug in the .NET framework. It is described in this article (http://connect.microsoft.com/VisualStud ... kID=428857) without a suggested work around. Fortunately a more complete article with a workaround can be found at http://www.scitech.se/blog/index.php/20 ... ork-20-sp1.
I have implemented the workaround described and can confirm that it solves the problem. You should note though that the reference will change anyway if/when another MDI child becomes the last active one. At that time the earlier one will be collected. So in a live system this probably isn't a big deal, but when using a memory profiler it does mis-lead.
I've seen a similar problem with a DevExpress tree component, but I have yet to find / come up with a workaround. I guess a simple example sent to DevExpress is the way forward.
Regards,
David.