Dispose of a class from within the class.

Hi folks.

I'm working on a test graphics app, I'm completely new to graphics, but I'm getting the hang of it. However, I have a class that needs to be completely self contained. The class will create (for now) a box which will move around the screen on a self contained timer until a random counter is reached.

There could be very many of these class objects flying about at any time and I could setup a load of variables on the main form to track all this data, but I'd far sooner pass the starting variables to the class and let it get on with it all, including disposing itself. This is the bit I can't find an answer to.

I can kill off a form from within the form, but I can't (with the help of google) find a way to kill a class object within the class itself. If it's possible. And I can't imagine it isn't, after all a form is basically a class.

As usual I don't want anyone to spend time writing working code for me, but if someone could point me in the right direction, or explain the principle I would be forever be thankful.
:)

Have you tried implementing IDisposable? Just add "Implements IDisposable" after the class name and press Enter. Visual studio will insert the boilerplate code, and there's no need to change it unless you are creating unmanaged objects in the class. Then you can dispose of the class when needed, or use it in a Using...End Using block.

BB

Yes, I've been looking at IDisposible, but it doesn't auto generate any code, and the samples I've looked at are somewhat confusing. To me anyway!

That's strange. You just put the Implements statement on the line after the Class statement and press Enter. As far as I can recall, that has been the same since Visual Studio 2003. It certainly works with VS2013, which I'm using now. If this isn't clear, can you post the code of your class (use [code]... [/code] tags)? BB

I beg your pardon, the code was created, I'm getting tired and should really give up for tonight, but I'm a stubborn sod!

Now I've found it I shall do some testing.

Thanks Boops, much appreciated. Without your push in that direction I would have given up on it!

Cheers.

I don't know how I haven't come across this before.

What I take from this is: If a class is destroyed and destroyed normally (not autonomous) a 'Nothing' should be all that's needed unless I have to deal with unmanaged stuff?

But this code is always needed if I'm killing an autonomous class?

You're not destroying the class, which is a blueprint for making objects, but an instance of the class. As far as I know, just setting an instance to Nothing makes the link between the instance and its identifier (variable name) invalid, but it doesn't mark the instance for garbage collection. Dispose does the latter. If you are not using PInvoke it probably doesn't make a lot of difference, but using Dispose instead of = Nothing will give the Garbage Collector a little less work to do.

This is pending comments by the real experts on this forum :wave:.

BB

Ok, understood.

Thank you very much for your help.

As far as garbage collection is concerned, you don't want to be saying when that runs, so it barely matters whether Dispose does anything special. The class will still sit there, it just won't be reachable by any code because no variable holds a reference to the class. It may sit there for the duration of your program, too, because the garbage collector will only clean it up when it needs to run, which might be never. The purpose of the IDisposable is to give you a means to release shared resources, or do any other clear up of system objects that is needed. If you don't have any of that stuff, then you don't need IDisposable, and in that case you wouldn't be able to call Dispose (because it won't exist), and that doesn't really matter. Setting a variable to Nothing often doesn't really do anything. If no variable holds a reference to the object then it is unreachable, that's all.

I'd suggest perhaps not making it entirely self-contained. If you have many instances of the class then they will all have their own timer. It would be better to have a single object containing a timer, and have it notify all the "flying box" instances when they need to update. Similarly, a single instance of a class that manages all your box instances would prevent your form from needing to know about all of the boxes, but also give you a single place to coordinate the creation/removal of the boxes.