Bohn
Bohn

Reputation: 26919

Memory Management of Interop objects

In an effort to fix possible memory leaks, here is the history behind it: There has been a VB 6.0 or VC 6.0 text editor control that we had to use it in .NET too. So in the assembloy for this control I see some Interop reference to this text editor and then we have created a .NET custom control, dropped that text editor into it and been usig that in projects that need it.

So in Designer.cs file I still see variables like this:

private AxTextEditorLib.AxTextEditor ctlTEEditor;

and then public properties like this:

[Obsolete("This accessor method was added as a convenience for migrating to this component. Remove at earliest convenience.")]
[Browsable(false)]
public AxTextEditor TextEditor
{
    get
    {
        return ctlTEEditor;
    }
}

.NET designer itself has generated that standard dispose method for this as follows:

protected override void Dispose(bool disposing)
{
    if (disposing && (components != null))
    {
        components.Dispose();
    }
    base.Dispose(disposing);
}

But is that enough? Do I need more memory handling to do? Do I need to use Marshal.ReleaseObjects or something like that? Do I need to release the event handlers manually?

enter image description here

Upvotes: 0

Views: 263

Answers (2)

humblelistener
humblelistener

Reputation: 1456

set ctlTEEditor to null if it not already null. Also check the public properties / methods of this control to see if there are any methods exposed to release the memory.

Upvotes: 1

Chamila Chulatunga
Chamila Chulatunga

Reputation: 4914

The effectiveness of calling Dispose() is alway dependent on what happens in the chain of Dispose calls. So in this instance, the Designer code is calling the Dispose method of each component that has been added to the components collection.

To work out whether that is useful, you need to look at what components are in the components collection, and what the Dispose methods of those components do.

Certainly if you have attached event handlers in other parts of the code, then you should ensure that they are unhooked as part of the Dispose.

For your wrapped component, it's worth setting it to null as part of disposal, but also have a look to see whether it has a Dispose method of its own, or any other methods that may be freeing up resources.

Upvotes: 1

Related Questions