Event Handler Destruction

[David Rogers]

When I, let's say I'm a form, register myself for an event, I use a syntax
such as:

Class1.EventNam e += new EventNameHandle r(MyFormsEventH andler);

Somewhere in global scope, I have defined the delegate EventNameHandle r:

public delegate void EventNameHandle r(object source, Eventargs e);

In Class1 I have:

public static event EventNameHandle r EventName;

I assume that the event EventName keeps track of all of the EventNameHandle r
delegates that are register with it. But who unregisters the delegate when
my form is destroyed? Can someone please explain?

Regards,
David Rogers

[Tobin Harris]

Re: Event Handler Destruction


"David Rogers" <drogers@NOSPAM .fhcrc.org> wrote in message
news:e7lQdWkbDH A.2928@tk2msftn gp13.phx.gbl...[color=blue]
> I assume that the event EventName keeps track of all of the[/color]
EventNameHandle r[color=blue]
> delegates that are register with it. But who unregisters the delegate when
> my form is destroyed? Can someone please explain?[/color]

I wondered about this, and used a heap profiler (.NETProfiler?) to
investigate what was going on. Basically, my forms were not dying until I
explicitly unregistered the delegates!! If you get hold of a heap profiler
(http://www.scitech.se/memprofiler/) you can investigate this yourself. I
supppose it kinda makes sense though, the forms are being referenced by the
delegates (by way of the callback), so the form shouldn't be garbage
collected until there is nothing in memory referencing it. I can't remember
if this is still the case even the delegate is set up between the form and a
control it contains?

Tobin
[color=blue]
> Regards,
> David Rogers
>
>[/color]

[Lee Alexander]

Re: Event Handler Destruction

Just to add, if want to unregister the delegate I find the best places for
adding and removing it are:

Control.OnHandl eCreated

and

Control.OnHandl eDestroyed

The Form class derives from Control so you can override them to do your
registering / unregistering.

Regards
Lee

"Jon Skeet" <skeet@pobox.co m> wrote in message
news:MPG.19b988 6782e3bcd898a42 9@news.microsof t.com...[color=blue]
> David Rogers <drogers@NOSPAM .fhcrc.org> wrote:[color=green]
> > When I, let's say I'm a form, register myself for an event, I use a[/color][/color]
syntax[color=blue][color=green]
> > such as:
> >
> > Class1.EventNam e += new EventNameHandle r(MyFormsEventH andler);
> >
> > Somewhere in global scope, I have defined the delegate EventNameHandle r:
> >
> > public delegate void EventNameHandle r(object source, Eventargs e);
> >
> > In Class1 I have:
> >
> > public static event EventNameHandle r EventName;
> >
> > I assume that the event EventName keeps track of all of the[/color][/color]
EventNameHandle r[color=blue][color=green]
> > delegates that are register with it. But who unregisters the delegate[/color][/color]
when[color=blue][color=green]
> > my form is destroyed? Can someone please explain?[/color]
>
> Unless you're doing it yourself, I don't believe anything is
> unregistering the event. Your form instance will stick around...
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too[/color]

[Jon Skeet]

Re: Event Handler Destruction

David Rogers <drogers@NOSPAM .fhcrc.org> wrote:[color=blue]
> Related question: Does the framework take care of the event handlers that
> are added to controls by the designer? If not, does this mean that my child
> form's button click handler is going to cause that form instance to remain
> in memory even after the form is gone?
>
> If that is the case, there must be 22 million programs out there that are
> leaking memory like a sieve![/color]

Not necessarily - it's only a memory leak if you're adding the delegate
to event *outside* the form itself. Normal forms where, say, clicking a
button triggers a label to change, don't have a memory leak - the whole
lot becomes eligible for garbage collection at the same time.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet/

If replying to the group, please do not mail me too

[Jay B. Harlow [MVP - Outlook]]

Re: Event Handler Destruction

David,
I do not believe in this instance its a problem, as the form has a reference
to the child & the child has a reference to the form. (circular references).

When you get ride of the form only that form references the children so
every thing should go away.

If your other example, form1 had a reference to form2, you had a reference
to form1, which was keeping every thing alive.

Hope this helps
Jay

"David Rogers" <drogers@NOSPAM .fhcrc.org> wrote in message
news:ORibY7kbDH A.620@TK2MSFTNG P11.phx.gbl...[color=blue]
> Related question: Does the framework take care of the event handlers that
> are added to controls by the designer? If not, does this mean that my[/color]
child[color=blue]
> form's button click handler is going to cause that form instance to remain
> in memory even after the form is gone?
>
> If that is the case, there must be 22 million programs out there that are
> leaking memory like a sieve!
>
> David
>
> "Lee Alexander" <lee@No_Spam_Pl ease_Digita.com > wrote in message
> news:e$l5%23jkb DHA.620@TK2MSFT NGP11.phx.gbl.. .[color=green]
> > Just to add, if want to unregister the delegate I find the best places[/color][/color]
for[color=blue][color=green]
> > adding and removing it are:
> >
> > Control.OnHandl eCreated
> >
> > and
> >
> > Control.OnHandl eDestroyed
> >
> > The Form class derives from Control so you can override them to do your
> > registering / unregistering.
> >
> > Regards
> > Lee
> >
> > "Jon Skeet" <skeet@pobox.co m> wrote in message
> > news:MPG.19b988 6782e3bcd898a42 9@news.microsof t.com...[color=darkred]
> > > David Rogers <drogers@NOSPAM .fhcrc.org> wrote:
> > > > When I, let's say I'm a form, register myself for an event, I use a[/color]
> > syntax[color=darkred]
> > > > such as:
> > > >
> > > > Class1.EventNam e += new EventNameHandle r(MyFormsEventH andler);
> > > >
> > > > Somewhere in global scope, I have defined the delegate[/color][/color]
> EventNameHandle r:[color=green][color=darkred]
> > > >
> > > > public delegate void EventNameHandle r(object source, Eventargs[/color][/color][/color]
e);[color=blue][color=green][color=darkred]
> > > >
> > > > In Class1 I have:
> > > >
> > > > public static event EventNameHandle r EventName;
> > > >
> > > > I assume that the event EventName keeps track of all of the[/color]
> > EventNameHandle r[color=darkred]
> > > > delegates that are register with it. But who unregisters the[/color][/color][/color]
delegate[color=blue][color=green]
> > when[color=darkred]
> > > > my form is destroyed? Can someone please explain?
> > >
> > > Unless you're doing it yourself, I don't believe anything is
> > > unregistering the event. Your form instance will stick around...
> > >
> > > --
> > > Jon Skeet - <skeet@pobox.co m>
> > > http://www.pobox.com/~skeet/
> > > If replying to the group, please do not mail me too[/color]
> >
> >[/color]
>
>[/color]

[Tobin Harris]

Re: Event Handler Destruction


"Jon Skeet" <skeet@pobox.co m> wrote in message
news:MPG.19b997 ecc99a03fc98a42 b@news.microsof t.com...[color=blue]
> David Rogers <drogers@NOSPAM .fhcrc.org> wrote:[color=green]
> > Related question: Does the framework take care of the event handlers[/color][/color]
that[color=blue][color=green]
> > are added to controls by the designer? If not, does this mean that my[/color][/color]
child[color=blue][color=green]
> > form's button click handler is going to cause that form instance to[/color][/color]
remain[color=blue][color=green]
> > in memory even after the form is gone?
> >
> > If that is the case, there must be 22 million programs out there that[/color][/color]
are[color=blue][color=green]
> > leaking memory like a sieve![/color]
>
> Not necessarily - it's only a memory leak if you're adding the delegate
> to event *outside* the form itself. Normal forms where, say, clicking a
> button triggers a label to change, don't have a memory leak - the whole
> lot becomes eligible for garbage collection at the same time.[/color]

[Kind of related comments!...]
That does make sense actually - and saves us a little effort. Still a pain
for me becuase I use a kind of MVC architecture where forms subscribe to
events in 'back end' classes. So, I always have to remember to explicitly
code the unsubscribe when the form is destroyed. Thinking about it, would it
be possible to create a deligate class that could respond to the subscribers
Disposed event? When this is fired, it could remove the object from it's
list of recipients? So then calling Form.Dispose() would automatically
unsubscribe it from any delegates it's referenced by? Does anyone know if
this is possible? I don't even know if you can create custom delegates
though!? Just thinking out loud...

Tobin
[color=blue]
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too[/color]

[David Rogers]

Re: Event Handler Destruction

Arghhhh! Of course not, the events themselves are destroyed with the form,
so there is no need to unregister the delegate instances that are registered
with those events...

Cheers!

"Jon Skeet" <skeet@pobox.co m> wrote in message
news:MPG.19b997 ecc99a03fc98a42 b@news.microsof t.com...[color=blue]
> David Rogers <drogers@NOSPAM .fhcrc.org> wrote:[color=green]
> > Related question: Does the framework take care of the event handlers[/color][/color]
that[color=blue][color=green]
> > are added to controls by the designer? If not, does this mean that my[/color][/color]
child[color=blue][color=green]
> > form's button click handler is going to cause that form instance to[/color][/color]
remain[color=blue][color=green]
> > in memory even after the form is gone?
> >
> > If that is the case, there must be 22 million programs out there that[/color][/color]
are[color=blue][color=green]
> > leaking memory like a sieve![/color]
>
> Not necessarily - it's only a memory leak if you're adding the delegate
> to event *outside* the form itself. Normal forms where, say, clicking a
> button triggers a label to change, don't have a memory leak - the whole
> lot becomes eligible for garbage collection at the same time.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too[/color]