[2005] Should I implement IDisposable?

[cptHotkeys]

Hi all

I am making a custom listview which inherits listview and handles all the owner drawing stuff using images, my listview has a three properties which are of type GraphicalRow, GraphicalRow is a structure which has a few images, a font and some other integers and such, along with a property wich is of type Graphical Header and is almost the same as above.

Now I have tried to find an awnser to this but im still not sure. The only custom types (Graphical Row, GraphicalHeader) in this class hold only generic types(is bitmap generic?) , so should I implement IDisposable or not?
And if I do, for generic types that dont have a dispose method, setting them to nothing is ok right?
eg. myinteger = nothing, or mybitmap = nothing.

or would just doing that to my UDT's be good enough, now I know I can get away without doing it at all but I want this to not get that one in a million error.

Thanks in advance

[jmcilhinney]

Are you creating any objects within your class that have a Dispose method themselves? If so then yes you MUST implement IDisposable; otherwise there's no point. I say that you must because if you don't then you will create a resource leak. In your Dispose method you simply call the Dispose method of those objects. That's all.

[cptHotkeys]

Yes I am, but only objects from the IO namespace, and maybe a binaryformatter if that does have a dispose method.

So is that enough to warrant an IDisposable implementation?

By the way, I wrapped the owner draw methods and the structures I mentioned in a class called GListViewStyle and I am considering creating an interface for the public methods and properties so that I can create listview style plugins, which would allow for a plugin to do the owner draw and display stuff. I would also put the functionality to load and initialize the ListViewStyles in the inherited listview(GListView). maybe even a dialog to load them and select one, but thats another subject.
Do I have to do any garbage collection with dynamicaly loaded assemblies, as far as I know the GC will clean them up when they go out of scope, does this change with dynamicaly loaded assemblies?
Tried to find an awnser but couldnt find the GC mentioned in relation to dynamicaly loaded assemblies.

Thanks allot...

[jmcilhinney]

If your class has any member variable whose type has a Dispose method then you should implement IDisposable. If it doesn't then you shouldn't. This is not a grey area. It's black and white: you either have managed resources and you implement IDisposable or you don't have managed resources and you don't implement IDisposable.

The only other reason to implement IDisposable is if you hold unmanaged resources directly, but I think it's probably safe to say that that's not the case.

[cptHotkeys]

OK, thanks alot.
So I must if any members have a dispose method, thanks...

So all objects created and-or manipulated outside the control of the Common Language Runtime (eg, ActiveX/Com objects) must have a .net accessible dispose or equivelant method otherwise they would cause memory leaks, correct?
And if Im creating an interface for plugins which may have any object at all, I must supply a dispose method in the interface too?

Cheers...

[jmcilhinney]

All ActiveX controls are wrapped in an instance of the Control class, which has a Dispose method.

You wouldn't declare a Dispose method in your own interface. If you knew for a fact that all types implementing that interface would need a Dispose method you should derive your own interface from IDisposable, so it inherits the Dispose method just as a derived class inherits the members of its base class. Any class that implements your interface must inherently implement IDisposable. Otherwise you'd just leave it up to the individual plug-in authors to implement IDisposable themselves if it was required. You can then use reflection to determine whether each individual object implements IDisposable and, if it does, then dispose it.

[cptHotkeys]

Thanks very much.

You have been very helpful.

Cya...