views:

109

answers:

3

I have an application that runs continuously, it creates and destroys classes some of which have events like mouse click events and the like... First question is what is the proper way to unsubscribe? If the subscribe looks like this:

Panel1.MouseClick += new MouseEventHandler(Action_MouseClick);

is it proper to unsubscribe like this:

Panel1.MouseClick -= new MouseEventHandler(Action_MouseClick);

OR is it ok to do this:

Panel1.MouseClick -= Action_MouseClick;

or is either way ok?

My other question is is If I use the Microsoft Visual C# studio to create the events through the designer, does it automatically unsubscribe as part of the 'Dispose' method? Or do I still need to put the unsubscribe method in the code?

+1  A: 

Either way of unsubscribing will have the same effect, and both are correct.

As for your other question .. if you use the designer to create events for controls on a form, when the form is disposed the source of the events no longer exists, so they won't be called. I guess I'm saying it isn't necessary to detach those events.

qstarin
Thanks qstarin ... I have noticed that the program will slowly leak memory and Im wondering if the class has been properly disposed of if I dont unsubscribe to some of the events that are set by the designer, meaning double-clicking on a Button in the designer will create the buttonClick event. But I havent been usubscribing to those events.According to the article:"http://msdn.microsoft.com/en-us/library/ms366768%28VS.80%29.aspx"Im wondering if the garbage collector is removing the object from the heap if I havent been usubscribing to those events.
From that article, "As long as the publishing object holds that reference, your subscriber object will not be garbage collected."A control on the form is the publishing object. The only reference to the control is its member variable in the form (usually the case, unless you hold onto a reference to the control specifically). Therefore, once the form is gone, the GC cannot reach the control, and consequently cannot reach the multicast delegate. All references are unreachable and should be collected.
qstarin
Alternatively, as a sanity check, I would think that if the the designer automagically subscribed, but did not automagically unsubscribe, and that caused a memory leak, then a whole lot of .Net apps would have this problem - and, perhaps obviously, that is not the case (or we would hear about it more, yes).
qstarin
I agree, but 90% of the applications out there dont continuosly run like mine does... its a display application that will show several objects then a timer will destroy all the objects on the screen and create new ones to show different data content... it will do this all day long over and over. I watch the memory in the Task manager grow and grow until it crashes. I try to dispose everything I can but obviously I'm not getting all of it. I have even tried calling the GC to no avail.I will go though everything and unsubscribe to all events no matter what and see what happens...
A: 

My other question is is If I use the Microsoft Visual C# studio to create the events through the designer, does it automatically unsubscribe as part of the 'Dispose' method? Or do I still need to put the unsubscribe method in the code?

From memory: no, it won't generate the un-subscribe code.

You can double check this yourself by opening the classname.designer.cs file and examining the generated Dispose method.

Mark Simpson
You are correct, it does not.
Ed Swangren
Thanks guys! I appreciate it...
Just an update... It does help to use 'Release' versions of the software you create... I have found that the system will remove memory allocated to the application much better than with 'Debug' versions.
A: 

The designer code won't automatically unsubscribe, but the subscriptions should not keep the controls alive as long as the form and all of its controls are no longer accessible from the application code. Lingering event handlers are mainly a problem when the subscriber and event producer have different lifetimes, which generally shouldn't be the case for a Form and its controls.

If you create/remove controls dynamically, you will probably want to manage the events, though it's not strictly necessary if the removed controls are no longer referenced and the removed controls stop firing events.

Dan Bryant