Object lifetime/event problem

[=?Utf-8?B?QmFycnkgR2lsYmVydA==?=]

I have a class that raises events that downstream objects subscribe to. In
one case, after destroying the object, the event seems to still get handled
in a subscriber object. So I instantiate an object and the event fires
correctly. Then I destroy the object and instantiate another instance and the
subscriber event handler get hit twice. I've tried using IDisposible and also
using GC.Collect, but it didn't seem to help. I've also tried using
RemoveHandler before destroying the object.

It's not clear to me whether the handler is firing because the objects are
still in memory or for some other reason.

Any help would be appreciated.

[Jeroen Mostert]

Re: Object lifetime/event problem

Barry Gilbert wrote:

I have a class that raises events that downstream objects subscribe to. In
one case, after destroying the object, the event seems to still get handled
in a subscriber object. So I instantiate an object and the event fires
correctly. Then I destroy the object and instantiate another instance and the
subscriber event handler get hit twice. I've tried using IDisposible and also
using GC.Collect, but it didn't seem to help. I've also tried using
RemoveHandler before destroying the object.
>
It's not clear to me whether the handler is firing because the objects are
still in memory or for some other reason.
>
Any help would be appreciated.

First of all, you can't explicitly "destroy" objects. You can call
..Dispose() on them, but that's it. That does not in itself do anything; the
object itself has to release resources. An object will stick around for as
long as there are references to it; when the last reference disappears, the
garbage collector will *eventually* reclaim the memory. Threads do not
belong to objects and will stick around until they either exit themselves or
(if flagged as background threads) the process exits.

When does your class raise events? In response to what? My guess is that
whatever you're using for that isn't stopped or signaled properly. The only
way to prevent the events from being raised is simply to not raise them. You
should know when not to raise them anymore because you should know when your
object is done doing whatever it's supposed to do (because someone called
..Dispose() or .Stop() or whatever, or because an external condition occurs).

--
J.

http://symbolsprose.blogspot.com

[Jack Jackson]

Re: Object lifetime/event problem

On Wed, 21 May 2008 08:31:01 -0700, Barry Gilbert
<BarryGilbert@d iscussions.micr osoft.comwrote:

>I have a class that raises events that downstream objects subscribe to. In
>one case, after destroying the object, the event seems to still get handled
>in a subscriber object. So I instantiate an object and the event fires
>correctly. Then I destroy the object and instantiate another instance and the
>subscriber event handler get hit twice. I've tried using IDisposible and also
>using GC.Collect, but it didn't seem to help. I've also tried using
>RemoveHandle r before destroying the object.
>
>It's not clear to me whether the handler is firing because the objects are
>still in memory or for some other reason.
>
>Any help would be appreciated.

Setting a reference to null does not make an object go away. It just
makes it eligible for garbage collection.

Suppose for example I create an instance of class X. In the
constructor the class creates an instance of a timer and sets the
timer to fire every second.

Immediately after creating the instance I set the reference to it to
null. Until the garbage collector runs and collects this instance,
the timer will continue to fire. The instance is still there, and
until the garbage collector runs and checks things no one knows that
there are no longer any references to the instance.

You say "the subscriber event handler get hit twice". Is that twice
for the same instance, or once for two different instances?

If twice for the same instance, then you have subscribed to the event
twice.

If for two different instances, then you need to find out why the
class that you no longer have references to is still generating
events.

Perhaps you need to implement IDispose in your classes, and have the
Dispose method 'turn off' the class - make it stop doing whatever
generates events. Then if you dispose of the class when you are
finished with it, it will stop generating events.

[Adam Benson]

Re: Object lifetime/event problem

When you destroy your subscriber object do you remove the event handler?

i.e.

// Shut down my subscriber object
Close()
{
WhereTheEventsC omeFrom.MyEvent -= new Event( this.EventHandl erRoutine );
}

If you don't do that the object raising the event still has a reference to
the subscriber. The result of this is that the subscriber will remain in
memory. Creating another one adds a new instance of the event handler - 2
objects now exist in memory, each one subscribing to the event.

I know you say you call RemoveHandler but the fact that your event is firing
twice suggests to me that your original object is still around, and is still
subscribing to the event.

HTH,

Adam.

"Barry Gilbert" <BarryGilbert@d iscussions.micr osoft.comwrote in message
news:A8968912-C6D2-42D4-A482-B5F5E521BF03@mi crosoft.com...

>I have a class that raises events that downstream objects subscribe to. In
one case, after destroying the object, the event seems to still get
handled
in a subscriber object. So I instantiate an object and the event fires
correctly. Then I destroy the object and instantiate another instance and
the
subscriber event handler get hit twice. I've tried using IDisposible and
also
using GC.Collect, but it didn't seem to help. I've also tried using
RemoveHandler before destroying the object.
>
It's not clear to me whether the handler is firing because the objects are
still in memory or for some other reason.
>
Any help would be appreciated.