Question

In my Silverlight application I have defined a datagrid with an template column containing a radio button as follows:

XAML:

<data:DataGrid x:Name="Grid1" Margin="8">
    <data:DataGrid.Columns>
        <data:DataGridTemplateColumn Header="RadioButtons">
            <data:DataGridTemplateColumn.CellTemplate>
                <DataTemplate>
                    <RadioButton x:Name="rdbIndataGrid" IsChecked="false" GroupName="myGroup" />
                </DataTemplate>
            </data:DataGridTemplateColumn.CellTemplate>
        </data:DataGridTemplateColumn>
    </data:DataGrid.Columns>
</data:DataGrid>

C#

    public MainPage()
    {
        // Required to initialize variables
        InitializeComponent();

        string data = "1,2,3,4,5,6,7,8,9";

        Grid1.ItemsSource = data.Split(',');
    }

When a button is clicked I want to be able to:

a) Find out which radio button was selected.

b) Get the data from one of the cells in the grid which corresponds to the selected radio button.

Is there an easy way to do this? There doesnt seem to be a rows collection on the grid. Or do I have to bind it to a datasource and then check the data source?

Many thanks.

Answer 1

The way I’d prefer to do this would be to bind IsChecked to a property of objects assigned to the ItemsSource. But here I’ll show you the hard way to do it

(Edit: Actually the following is over complicated for this scenario but I’ll leave it here for now, see edits after)

First you need one of my VisualTreeEnumeration extension methods:-

public static class VisualTreeEnumeration
{

    public static IEnumerable<DependencyObject> Ancestors(this DependencyObject root)
    {
        DependencyObject current = VisualTreeHelper.GetParent(root);
        while (current != null)
        {
            yield return current;
            current = VisualTreeHelper.GetParent(current);
        }
    }
}

Now in my testing I’ve just added a ListBox with the name lstOutput to my Xaml. Now add the following couple of event handlers to you UserControl :-

    private void rdbIndataGrid_Checked(object sender, RoutedEventArgs e)
    {
        DataGridRow row = ((DependencyObject)sender).Ancestors().OfType<DataGridRow>().FirstOrDefault();
        if (row != null)
            lstOutput.Items.Add(String.Format("Checked: {0}", row.DataContext));
    }

    private void rdbIndataGrid_Unchecked(object sender, RoutedEventArgs e)
    {
        DataGridRow row = ((DependencyObject)sender).Ancestors().OfType<DataGridRow>().FirstOrDefault();
        if (row != null)
            lstOutput.Items.Add(String.Format("Unchecked: {0}", row.DataContext));
    }

and finally tweak the Radio button Xaml like so:-

<RadioButton x:Name="rdbIndataGrid" IsChecked="false" GroupName="myGroup"
    Checked="rdbIndataGrid_Checked" Unchecked="rdbIndataGrid_Unchecked"  />

(One of the neat things about Xaml wiring up events is that it works even when the elements are part of a Template).

You’ll note that in the event handlers I’m walking up the visual tree from the sending RadioButton to find the containing DataGridRow. The DataGridRow is the object that its DataContext set to the object being rendered by that row. In your own code you could cast the data context value to the correct type and from there access other data about the row.

Edit

Actually in most ordinary cases you don’t need to hunt down the owning DataGridRow object accessing the DataContext property of the sending RadioButton is sufficient:-

    private void rdbIndataGrid_Checked(object sender, RoutedEventArgs e)
    {
        object myData = ((FrameworkElement)sender).DataContext;

        if (myData != null)
            lstOutput.Items.Add(String.Format("Checked: {0}", myData));
    }

    private void rdbIndataGrid_Unchecked(object sender, RoutedEventArgs e)
    {
        object myData = ((FrameworkElement)sender).DataContext;
        if (myData != null)
            lstOutput.Items.Add(String.Format("Unchecked: {0}", myData));
    }

Hence you can dispense with the Ancestors extension method. However in more complex cases where the DataContext have been changed the original “over-complicated” approach may be needed.