In WPF, SelectionChanged does not mean that the selection changed

Windows Presentation Foundation's Routed Events can lead to unexpected or at least nonintuitive behavior when using TabControls that contain ListViews and/or ComboBoxes. A routed event generally bubbles from the control that raised it, up the whole element tree until the root. On its way up it invokes handlers on multiple listeners. This makes a lot of sense in the ButtonBase.Click Event: if a button is clicked, then its containing element is also clicked.

By design, the Selector.SelectionChanged Event is such a routed event. TabItem, ListBox, and ComboBox all inherit from Selector, so if you put them in a hierarchy they will register on each other's events. A ComboBox that appears via a template in a ListBox will raise the SelectionChanged event of that ListBox - even if the user didn't select a new ListBoxItem. If you put that ListBox in a TabControl, then the SelectionChanged on that TabControl will also be fired - even if the user didn't select a new TabItem.

Enough talking: let's build a small demo. First we build a Window with a TabControl that has a ComboBox in its first TabItem:

XAML

<Window x:Class="DockOfTheBay.SelectorSampleWindow"
       xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
       Title="Selector sample" Height="200" Width="400" >
    <Grid>
        <TabControl
           x:Name="MainTabControl"
           SelectionChanged="MainTabControl_SelectionChanged" >
            <TabItem Header="Courses" >
                <TabItem.Content>
                    <ListBox x:Name="ListBox1" />
                </TabItem.Content>
            </TabItem>
            <TabItem Header="Classrooms" >
            </TabItem>
        </TabControl>
    </Grid>
</Window>

C#

/// <summary>
/// The selection in the main tab control was changed.
/// </summary>
/// <param name="sender">Sender of the event: the Main Tab.</param>
/// <param name="e">Event arguments.</param>
private void MainTabControl_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    // First Tab
    if (this.MainTabControl.SelectedIndex == 0)
    {
        // (Re-)Populate ListBox
        this.ListBox1.Items.Clear();
        this.ListBox1.Items.Add("Building Windows Applications with WPF, LINQ and WCF");
        this.ListBox1.Items.Add("Building Cloud based Enterprise Applications for Windows Azure");
        this.ListBox1.Items.Add("Designing Data Warehouses using Dimensional Modeling");
        this.ListBox1.Items.Add("Upgrade to SharePoint 2010");
    }
}



Switching from one tab to another behaves nicely. Unfortunately, clicking in the ListBox now also triggers the SelectionChanged event from the TabControl itself, resulting in unexpected behavior:



Before diving into solutions, let's make it worse by implementing a very popular pattern. When the user navigates to a new TabItem, we populate a ListBox, and programatically select its first item. In theory there's nothing wrong with this, in practice it creates an infinite loop (well, it's not really infinite: it stops when you're out of stack space):



We can solve this by letting the child controls prevent the event from propagating -via the Handled property- like this:

XAML

<TabItem Header="Courses" >
    <TabItem.Content>
        <ListBox x:Name="ListBox1"
                SelectionChanged="ListBox1_SelectionChanged" />
    </TabItem.Content>
</TabItem>

C#

/// <summary>
/// The selection in the listbox was changed.
/// </summary>
/// <param name="sender">Sender of the event: the ListBox.</param>
/// <param name="e">Event arguments.</param>
private void ListBox1_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    // Stop the event from bubbling.
    e.Handled = true;
}

Of course, not all child controls will have an event handler or even need one (e.g. a ComboBox bound to a property of a Business Entity). Moreover, the parent control can not depend on the implementation of his children. Fortunately the parent control can decide to ignore all bubbled events from child controls like this:

C#

/// <summary>
/// The selection in the main tab control was changed.
/// </summary>
/// <param name="sender">Sender of the event: the Main Tab.</param>
/// <param name="e">Event arguments.</param>
private void MainTabControl_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
    // Ignore Routed Events from children
    if (e.OriginalSource == this.MainTabControl)
    {
        // First Tab
        if (this.MainTabControl.SelectedIndex == 0)
        {
            // (Re-)Populate ListBox
            this.ListBox1.Items.Clear();
            this.ListBox1.Items.Add("Building Windows Applications with WPF, LINQ and WCF");
            this.ListBox1.Items.Add("Building Cloud based Enterprise Applications for Windows Azure");
            this.ListBox1.Items.Add("Designing Data Warehouses using Dimensional Modeling");
            this.ListBox1.Items.Add("Upgrade to SharePoint 2010");

            // Select first item (no more 'Kaboom')
            this.ListBox1.SelectedIndex = 0;
        }
    }
}

In practice this means that you should program this check on OriginalSource not only in every TabControl (because its TabItems can contain ListBoxes and ComboBoxes), but also in every ListBox (because its template can contain ComboBoxes).

5 comments:

  1. Thanks, your article is very useful.

    ReplyDelete
  2. Thank you, well described and very useful.

    ReplyDelete
  3. Thanks! I used "if(sender == e.OriginalSource)" instead, in order to recycle the method.

    ReplyDelete
  4. thanks, how to do that in xaml for mvvm?

    ReplyDelete
  5. If you want your ex-girlfriend or ex-boyfriend to come crawling back to you on their knees (no matter why you broke up) you gotta watch this video
    right away...

    (VIDEO) Text Your Ex Back?

    ReplyDelete