1

I have an assembly that have drag dropped a COM Interop VB 6.0 text editor in it and been using it as a .NET wrapped control... Then in a new assembly that is a windows form I drag drop the assembly above and start using it, declare a variable of it and assign event handlers to it so for example if Assmbley abvoe is namved MyTextControl then in this windows form I have a variable of mytxtcntrl and some event handlers for it like 

mytxtcntrl.TextEditor.ObjectDblClicked += new AxTextEditorLib._DTextEditorEvents_ObjectDblClickedEventHandler(ctlTEEditor_ObjectDblClicked);

So now Sholud I even worry about removing these event handlers with "-=" ? or GC will take care of it? If I should do it manually then what is the correct place to do it? I put them in Form_Closed section and ran a memory profiler, it didn't have any effect.

Bohn
  • 26,091
  • 61
  • 167
  • 254
  • 1
    I haven't dealt with ActiveX controls in .NET in a while, but there used to be a bug in .NET that kept it from cleanly getting rid of ActiveX controls after the form was closed and disposed, so it is probably a good idea to unsubscribe. Unsubscribing in Close or overriding the form's Dispose(bool) should be fine. – Pete Dec 11 '12 at 16:30

2 Answers2

3

Unsubscribing events explicitly is only required when the event source object outlives the event subscriber. Not doing so will keep a reference to the objects that subscribe, preventing them from being garbage collected.

Winforms was pretty carefully designed to avoid that kind of mishap. You'd normally write an event handler in a form or user control to listen to events fired by the child controls. The lifetime of those child controls is closely associated with the lifetime of the form, they all get disposed at the same time when the user closes the form. The garbage collector will not be stumped by this and collects them all at the same time.

Your ActiveX control fits this pattern, it will be a child control of your form so dies at the exact same time the form dies. No need for explicit cleanup at all.

There are a few corner cases where this will not work as described. A classic one is where you remove a control yourself in your own code but keep the form alive. Now you should unsubscribe any events to allow that control to be garbage collected. And most importantly, you have to explicitly call Dispose() on the control as well to ensure the native window for it is destroyed. Not doing so produces a permanent leak that not even the garbage collector can solve, a control is kept alive by its window handle.

The second case is the SystemEvents class. Its events are static, the class object lives until your program terminates. You always have to explicitly unsubscribe its events if you use them in a form that may be closed without otherwise terminating the app.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
2

No, you shouldn't. The GC will take care of it. The only place where you need to worry about "trowing away" objects, is when you are using a class which implements IDisposable or when you're doing stuff with System.Runtime.InteropServices.

antonijn
  • 5,702
  • 2
  • 26
  • 33
  • That's not entirely true, one of the main reasons for memory leaks in .NET is due to event handlers not being un-registered. – Trevor Pilley Dec 11 '12 at 16:35
  • "when you are using a class which implements IDisposable" Ok I have these too, one of my classes is implementing IDisposable and again it has a variable of that textEditor type in it. In that case where is the correct place to remove event handlers? – Bohn Dec 11 '12 at 16:35
  • @TrevorPilley Interesting, have you got any source for this? – antonijn Dec 11 '12 at 16:51
  • 1
    @BDotA You didn't entirely get the point. You never need to remove event handlers. I was saying that you DO have to take care of classes implementing IDisposable, and taking care means calling Dispose(), not remove event handlers. – antonijn Dec 11 '12 at 16:53
  • 2
    http://stackoverflow.com/questions/4526829/why-and-how-to-avoid-event-handler-memory-leaks – Pete Dec 11 '12 at 17:16