Problem with add/remove accessor in Event

[Ty]

Hi all

i'm playing a bit with automatic ressource cleaning. here's my
problem. Little test code:

public class TestClass
{
public event EventHandler OnFire;

private void TestMethod()
{
OnFire.GetInvocationList();
}
}


This compiles fine (disregard that OnFire.GetInvocationList() doesn't
do anything useful)


Now if i try to add accessors to the OnFire-event like this:

public class TestClass
{
public event EventHandler OnFire
{
add{}
remove{}
}

private void TestMethod()
{
OnFire.GetInvocationList();
}
}

I get this error with OnFire.GetInvocationList()
** The event 'OnFire' can only appear on the left hand side of += or -
=


is there a way to define cusom-accessors and still have all Methods of
"OnFire" available?


Thank you!

 

[miher]

Hi,

As i know when You omit the add/remove accessors the compiler auto generates
a private backing field with the same name that Your event. I dont know how
that works out but i think that when You reference an "event name" with an
auto generated backing field, the auto generated field will be referenced.

However when You use the add/remove accessors this backing field wont be
auto-generated, so You have to do it Yourself:

private EventHandler _Fire;

public event EventHandler Fire
{
add { _Fire += value; }
remove { _Fire += value; }
}

public void InvocationList()
{
Delegate[] d = _Fire.GetInvocationList();
// ....
}


Hope You find this useful.
-Zsolt

 

[Ty]

.NET is a garbage-collecting system.  It's very likely that if you see a
need for "automatic resource cleaning", there's something wrong with your
code.

Hi Pete

i absolutely agree with you. But in certain situation this is not
working as desired. in our application we have some central processing
classes wich are only instantiated once. For example, one is listening
to network traffic and is firing events to notify gui-elements of the
application, it's an application with MDIParent and childs.
Now if forms and controls are subscribing to events of those classes
and are closed/disposed later on, they will recide in memory if not
every event is unsubscribed and they will continue doing their work
indefinetly, invisibly, hogging ressources. of course, right now we
are unsubscribing the events in the dispose method. but you have to be
very careful to really unsubscribe all events, wich is not that easy
on such a interactive and asynced application.

and i'm lazy so in my opinion, if a form/control is disposed, an
event should automatically nullify the delegates linking to these
controls.

i've been playing arround a bit and potentially this could be very
comfortable. i made a method to add delegates to a event in one of
those baseclasses. the method would check if the Delegate.Target is
Control, subscribe to it's dispose-event and automically set all
delegates to the control to null if the control is disposed.
this works very well. but i would like to make this invisible for the
subscribing classes, hence my question. right now i'm thinking about
doing a EventHandler that is capable of this kind of additional work.

IMO there is absolutly no point firing events to a disposed control
and i had a hard time believing .NET is not taking care of this
already.

Am i missing something? do you have another suggestion how to solve
this?

Thank you!