One key feature of C# as a language is its event support. While the basic infrastructure has remained substantially unchanged from the original 1.0 version of C#, the supporting syntax has become progressively cleaner and clearer.

In the recently released C# 3.0, lambda expressions coupled with enhanced type inference give the simplest syntax yet.

Let’s start at the beginning, and see how things have changed over time.

In C# 1.0, hooking up a method to be called when a button is pressed looked something like this:

public void MyMethod()
{
    ...
    Button myButton = new Button();
    myButton.Text = "Increase";
    Button.Click += new EventHandler(ButtonClicked);
    ...
}
 
private void ButtonClicked(object sender, EventArgs e)
{
    Value += 100;
}

Note how we needed to explicitly create an EventHandler object to wrap the method before registering for the event.

C# 2.0 made this a little simpler by having the compiler automatically insert the construction of the Event Handler where it was needed:

public void MyMethod()
{
    ...
    Button myButton = new Button();
    myButton.Text = "Increase";
    Button.Click += ButtonClicked;  // No longer need to wrap the method
    ...
}
 
private void ButtonClicked(object sender, EventArgs e)
{
    Value += 100;
}

In fact, anonymous methods allow us to get rid of the supporting method altogether:

public void MyMethod()
{
    ...
    Button myButton = new Button();
    myButton.Text = "Increase";
    Button.Click += 
        delegate(object sender, EventArgs e)
        {
            Value += 100;
        };
    ...
}

Though, doing this means that we can’t easy deregister the event later if needed. But, often we don’t need to do this.

Since Lambda Expressions provide an equivalent, more compact syntax, we can restate this:

public void MyMethod()
{
    ...
    Button myButton = new Button();
    myButton.Text = "Increase";
    Button.Click += 
        (s, a) => Value += 100;
    ...
}

As you can see, using a lambda expression in this way to register for an event is both concise and simple. Type inference makes everything work sweetly in Visual Studio, and the expression gains access to local variables as required.

On the down side, deregistration of the event isn’t possible (as no reference to the lambda expression is retained), and the unusual construct may be a minor hurdle for future maintenance by inexperienced developers.

Purely as a matter of style, I’ve found that spreading the event registration over two lines is easier to read than compressing the whole thing onto one. Your milage may vary, of course.

Comments

blog comments powered by Disqus
Next Post
Why Crystal Reports Sucks  29 Mar 2008
Prior Post
No longer the C# we knew  21 Mar 2008
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
Archives
March 2008
2008