Question

I have a ugly piece of code that adds event handlers. The problem is, if the code is called multiple times, the event handlers are called multiple times.

To solve the problem, I remove the event handler first and then add it.

Now I’ve seen the following behaviour:

Some event handlers can be checked like:

if (object.event == null) {
    //
    // Code
    //
}

others of the form

if (object.object.event == null) {
    //
    // Code
    //
}

I get a message like ‘object.object.event’ may only occur left of -= or +=.
(Since I’m using a german version of visual studio, I don’t know the correct translation to english).

I have no idea why the behaviour looks this inconsequent so I would be grateful for some information on this.

To be more specific: It’s user control.

if (myControl.Event == null) {
    //
    // works
    //
}

if (myControl.TreeView.NodeMouseClick == null) {
    //
    // doesn't work
    //
}

Answer 1

SLaks is correct, and has linked to some excellent resources. Here’s a relevant quote from Chris Burrows’ blog article:

Let me take a quick detour here and explain to you how the binding of += works in C#. There are two possibilities:

1. either there is an actual + operator, such as with ints, and x += y binds to “x = x + y” except that x is only evaluated once. This is the compound assignment operator; or
2. the thing on the left hand side is an event, and x.E += y binds to “x.add_E(y)”. This is the event accessor operator, and in fact this is the only way to bind to an event accessor.

So what do we have in the snippet above? Well, the extra bit of detail that you need to decide is the following rule about field-like events in C#: outside of the class or struct that defines a field-like event E, binding to the name E resolves to the event itself, on which the only legal operation is calling an accessor; inside the class or struct that defines a field-like event E, binding to the name E resolves to the private delegate field.

In your case, when resolving myControl.Event, you’re inside the myControl class, so you don’t see an event object; instead you see an actual delegate object, which you can compare with null. When resolving myControl.TreeView.NodeMouseClick, you’re outside the TreeView class, so you can’t access the actual delegate object; all you get is the event object, which cannot be compared to null.

If I understand correctly, all of this wouldn’t help you anyway, since presumably after you check for null, you’re going to try to fire the TreeView‘s event for it, which you can’t do.

Depending on what you’re trying to do, you could probably subclass TreeView and add an internal method that would call the protected TreeView.OnNodeMouseClick method to fire the event.