#597 – Naming Conventions for Event Handlers

It’s customary to use the following convention when naming event handlers:


For example, if you were attaching a handler for the Click event to a Button and the button was labeled “Like”, you might name the handler btnLike_Click.

        <Label Content="Tractors"/>
        <Button Content="Like" Click="btnLike_Click"/>

Even though the Button control isn’t actually named, you can still use meaningful control names when naming event handlers.  In the example above, I’ve used a the “btn” three-letter prefix to refer to a Button.  Some other common control prefixes for naming purposes are:

  • cbo – ComboBox
  • chk – CheckBox
  • cnv – Canvas
  • dg – DataGrid
  • lbo – ListBox
  • lbl – Label
  • mnu – Menu
  • sp – StackPanel
  • tbl – TextBlock
  • txt – TextBox
  • win – Window

#582 – Events Are Routed Even When a Handler is Not Defined

When a routed event is fired and the event travels up (bubbles) or down (tunnels) the logical and visual trees, corresponding event handlers will fire for any controls that have defined an event handler that matches the event.

However, whether or not you have handlers defined, the event will continue to travel up (or down) the tree, looking for controls that have handlers defined.  In the example below, a KeyDown event in the TextBox fires an event in the TextBox and then in the main Window.

    xmlns:d="http://schemas.microsoft.com/expression/blend/2008" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
	x:Name="Window" Title="Routed Events" Width="400"

    <StackPanel Orientation="Vertical">
        <Label Content="Some good movies:"/>
        <StackPanel Orientation="Horizontal" Margin="10" >
            <Label Content="Lawrence of Arabia" FontWeight="Bold"/>
            <Label Content="David Lean"/>
            <Button Content="Like" Padding="8,0"/>
            <TextBox Width="75" Margin="5,2" KeyDown="tbLawrence_KeyDown"/>
        <StackPanel Orientation="Horizontal" Margin="10">
            <Label Content="Schindler's List" FontWeight="Bold"/>
            <Label Content="Steven Spielberg"/>
            <Button Content="Like" Padding="8,0"/>

#499 – Interacting with the Control That Initiated an Event

In WPF, you do not have to provide a name for every control in your user interface.  Since so much is accomplished through data binding, you often don’t need to interact with a control at all from your code.

But one scenario where you might want to interact with a control is from an event handler for an event that the control initiated.  Every event handler will have a sender argument that represents the control that fired the event.  You can cast this argument to the appropriate type to get at the original control.

<Button Content="Click Me" HorizontalAlignment="Center" Padding="10,5" Margin="10"
        private void Button_Click(object sender, RoutedEventArgs e)
            Button b = sender as Button;
            b.Width = b.ActualWidth + 1;

#345 – WPF Command Model is Preferred over Traditional Event Handler Model

In an application, you often need to execute some code in response to a user action.  In WPF, you can use the new command model to respond to user actions or you can use the event handler model that Windows Forms used.

In the event handler model, you wire up event handlers to the code that does the actual work.

With this approach, you still have to add all of the individual event handlers and you need to write code to manage state, i.e. figure out when the user is allowed to click the buttons/menus and enable/disable them.

In the WPF command model, a single command object is bound to the handler code and each control links to that command.  The command object also adds support for state.

So the benefits of the WPF command model are:

  • Less plumbing code to write (no event handlers)
  • Automatically handle control enabled/disabled state