Question

I have several RadioButtons combined in one Group so that only one can be checked. The RadioButtons are bound to boolean Properties.

This works very well and my program reacts on the changes of these Properties.

Suppose optA is selected. Next I select optB, the value of PropertyB is set to true and my program reacts accordingly. However, at this time both optA and optB are true until the Group of Radio buttons updates optA to false which again triggers my “IsSelected” event.

I think this is totally correct behavior…
But how can I distinguish between a change from the user and the automated change from the group?

Edit: Code

<RadioButton Name="featureCheckBox" GroupName="featureRadioButtonGroup" IsChecked="{Binding Path=IsSelected, Mode=TwoWay}" />

 public bool IsSelected { 

        get{ return _isSelected; }
        set { PropertyChanged.ChangeAndNotify(ref _isSelected, value, () => IsSelected); }
    }

Answer 1

First of all to answer your question.

Change the set portion of the IsSelected property as follows. (You will of course have to write the actual code for the if statement)

public bool IsSelected 
{ 

    get{ return _isSelected; }
    set 
    {
        //If two options are true wait for the second change of values
        //You will now only get One notification per change.
        if (twoOptions are selected) return;
        else PropertyChanged.ChangeAndNotify(ref _isSelected, value, () => IsSelected); 
    }
}

You could instead just listen for false values but then you’d have to set an arbitrary options to true to begin with. Or you could just listen for true values and ignore all false values which means you will have problems with multiple Properties being true until the group box updates the old option to false.

Now for the advice.

A much better model would be this.

1. Create a boolean property for each option. (optA, optB, optC, etc.)
2. When one of these properties is set to true, set all the other options to false via code in the model where the properties are declared.
3. Bind each radio button to an option but do NOT group them. (Grouping them causes the UI to force the selection of only one. This does not lend itself to separation of UI and business logic.)

Several benefits of doing it this way.

1. You can rip out the UI and change it to something else without changing the business logic. (In other words you could bind the properties to RadioButtons, ToggleButtons, etc. without having to change ANY code.)
2. You can more easily unit test your business logic because a UI isn’t even required.
3. You can implement custom grouping of your options. (maybe you’ll add optZ that is actually valid to be selected along with optC. In this case you’d want to switch away from radio buttons since they indicate that only one option may be selected at a time)