C# Event Handling Methods

Question

Since I have started learning C#, I have seen a few ways to handle events. Say I have a XAML button like this:

<Button x:Name="button" Content="Click me!"/>

Given this button, I have can hook up a click event in several ways:

Modify the Click property of the button to point to a method in the code behind like:

<Button x:Name="button" Content="Click me!" Click="button_Click"/>

And then add that button_Click method to the code:

private void button_Click(object sender, RoutedEventArgs e)
{
    button.Content = "Ow >_<";
}

Handle the event through a delegate in the code behind:

button.Click += delegate 
{
    button.Content = "Ow >_<";
};

Handle the event through a lambda expression in the code behind:

button.Click += (object sender, RoutedEventArgs e) =>
{
    button.Content = "Ow >_<";
};

Given these three methods, I have a couple of questions:

What is the fundamental difference between these methods.
Are there any cases in which one method should be used instead of another. I have seen type 1 used mainly in WPF and WinRT application, but the other two I have only really seen when using Xamarin.

score 2 · Answer 1 · answered Sep 14 '15 at 00:29

is not specific to WPF or WinRT, it is typical in .NET in the GUI designer to click on the control to wire up default events or click on the events in the properties window of visual studio. This is how you are going to wire up events to the controls most of the time. You typically wire events up using 2. or 3. when you are creating dynamic controls at runtime, and the events themselves are not different, but the stage in which they are created in the life cycle of your application makes a lot of difference for 2. and 3..

score 2 · Answer 2 · edited May 23 '17 at 10:27

2

What is the fundamental difference between these methods?

There is no fundamental difference. They are just different ways to register a handler to an event.

Another way (and a recommended way for a more maintainable application) to handle events is actually by separating the view (the GUI) from the view model (the logic behind the view). This is called the MVVM pattern. WPF supports data binding and this allows you to define a command in your view model class and then you can attach the button in XAML to such command.

Take a look at this stackoverflow question for more information about this.

edited May 23 '17 at 10:27

Community

1
1

answered Sep 14 '15 at 00:32

Yacoub Massad

27,509
2
36
62

You mentioned WPF, but can the same MVVM pattern be used in WinRT Universal apps? – James Parsons Sep 14 '15 at 00:38
1

I've never worked with Universal Apps, but a quick google search shows some examples on how to do that. – Yacoub Massad Sep 14 '15 at 00:44

score 1 · Accepted Answer · answered Sep 14 '15 at 02:22

From a memory leakage perspective, you would try to avoid approaches #2 and #3 unless you are absolutely sure that these are one-off event subscriptions. Reason being, how would you unsubscribe these?

The challenge isn't readily visible when you write a trivial sample code. But what if it was a view model being created dynamically over and over again, based on a user double-clicking on a list (or something like that), and this VM was hooking a handler to another class' event? When one or more of these VMs go out of scope, how would you clear out the event subscription? A typical subscription removal would look like:

otherClass.SomeEvent -= myHandler;

But how would you do that if you're using an anonymous delegate, or a lambda? This becomes a nightmare if you somehow introduce 2 or more lambdas with signatures that .NET decides are equal. Argh.

C# Event Handling Methods

3 Answers3