Why the NEW Keyword When Removing an Event

[Guadala Harry]

In the following line of code, what is the point of including the 'new'
keyword?

List.Changed -= new ChangedEventHandler(ListChanged);

I'm just a bit confused because I thought 'new' was used to instantiate a
new instance of a class - and in this case, were removing an 'existing'
instance of the ChangedEventHandler delegate from the List.Changed event.

Thanks.

 

[Frank Oquendo]

I'm just a bit confused because I thought 'new' was used to
instantiate a new instance of a class - and in this case, were
removing an 'existing' instance of the ChangedEventHandler delegate
from the List.Changed event.

It would seem the author of that code was confused too. You're right about
not removing an existing delegate. To do that, you'd need to store a
reference to the delegate when it's first created than pass that reference
when it's time to disconnect.

--
There are 10 kinds of people. Those who understand binary and those who
don't.

http://code.acadx.com
(Pull the pin to reply)

 

[Roy Fine]

In the following line of code, what is the point of including the 'new'
keyword?

List.Changed -= new ChangedEventHandler(ListChanged);

I'm just a bit confused because I thought 'new' was used to instantiate a
new instance of a class - and in this case, were removing an 'existing'
instance of the ChangedEventHandler delegate from the List.Changed event.

Thanks.

The += operator (and the + operator for the more general case) will add a
delegate to the event. In part, the delegate in this case, defines a method
and either a class (for a static method) or an instance.

The -= operator will remove a delegate - but you must specify which delegate
to remove - this is done by identifying the method and the class or instance
object. The only mechanism that we have to do this is through the new
XXXX(yyyy) where XXXX is a type speficier for the delegate, and yyyy
identifies the method and class/instance object.

Consider the following:

List.Changed = new ChangedEventHandler(MyMethod1);
List.Changed += new ChangedEventHandler(MyMethod2);
....
List.Changed -= new ChangedEventHandler(MyMethod1);

This sequence will create an event with one delegate, then create another
event with the first plus one more (events are immutable - things are not
added to nor subtracted from then). Finally, a third event will be created,
but the MyMethod1 delegate will not be there. The second delegate for
MyMethod2 was created ONLY to get the method and class/instance object,
nothing more.

Had one found the prescience to keep a reference to the first delegate, one
might then be able to do something like this:

List.Changed = myDelegate = new ChangedEventHandler(MyMethod1);
List.Changed += new ChangedEventHandler(MyMethod2);
....
List.Changed -= myDelegate;

While that may be a bit more efficient, it's functionally equivalent with
the code above.

regards
roy fine

 

[Matthew W. Jackson]

No, since the remove handler function uses Object.Equals to find a delegate
to remove from the invocation list, and because the Equals method of a
delegate has been overridden to compare the target object and the target
function (rather than reference equality).

Passing in a new delegate object pointing to the same object and function
will in fact remove the original delegate from the invocation list.

There's no need to store the delegate. In fact, I would dare say the memory
wasted in storing such a reference is not worth the very-very-small
performance hit of constructing a new delegate in order to remove an
existing one from the list.

I admit, the syntax is a bit confusing, but this should be "fixed" in the
next version of C#, where you will just type the following:

List.Changed += ListChanged;

and

List.Changed -= ListChanged;

--Matthew W. Jackson