Responding to RadioButton 'IsCheckedChanged' event is awkward and misleading

[TangDave]

There are two problems with handling the 'IsCheckedChanged' event for Avalonia RadioButtons:

1. Fires twice - first for the radio button becoming checked and then for the radio button becoming unchecked. The is more of an annoyance and other frameworks have the same behavior.

2. A more serious problem is that the 'IsChecked' values are incorrect on the first event firing - both the radio button changing its 'IsChecked' property from 'false' to 'true' has 'IsChecked' equal to 'true' and the radio button changing from 'true' to 'false' also has its 'IsChecked' equal to 'true'. The only time it's correct is the second firing of the event.

private void SomeRadioButtonGroup_IsCheckedChanged(object sender, RoutedEventArgs e)
{
	//wait until the 'IsChecked' property is 'false' for two reasons:
	//1. avoid duplicate processing of radio button IsCheckedChanged event
	//2. only when the 'IsChecked' property is 'false' are all radio button 'IsChecked' values correct!
	if (!((RadioButton)sender).IsChecked.Value)
	{
		if (this.optFoo.IsChecked.Value)
			EnableFooPerspective();
		else
			EnableBarPerspective();
	}
}

The above code correctly handles the event without duplication, and more importantly, without error. The is very awkward though. How do others handle these 2 problems?

[robloo]

Point 1:

IsCheckedChanged is designed to fire for BOTH checked and unchecked (and indeterminate). This follows WinUI's ToggleSplitButton which has the most recent API design. An opportunity was taken in 11.0 to upgrade the API for all ToggleButton-like controls to match this same convention #9556.

Point 2:

You should always be able to get the current status of the property within the event using var value = (sender as RadioButton)?.IsChecked. Changed indicates the action has already happened. If this is not firing in order correctly it's a bug.

[TangDave]

It's a bug then - to reproduce just have 2 radio buttons which both specify a common handler for the 'IsCheckedChanged' event. In the event handler, set two booleans equal to the 'IsChecked.Value' of each button. You'll see that the first time the event fires, they will both be 'true'. Only during the second time the event fires (they fire in pairs), will one be true and one be false.

[robloo]

Ah, for RadioButtons this is actually correct behavior I think. We have no RadioButtonGroup concept in Avalonia and each radio button is it's own control. The first control changes state, then the second control changes state. In the intermediate after the first changes the state for both with be true.

We would have to compare with behavior with WPF at this point.

[TangDave]

Ok. My code to deal with this works, but I was curious about a more elegant way to handle it.

[robloo]

The most elegant way to handle this isn't to use the event handler at all. Have an enum with values that represent each radio button selection. Then expose that selected value enum as a property on your view model. Then you can bind directly to the radio buttons as done in the color picker:

Avalonia/src/Avalonia.Controls.ColorPicker/Themes/Fluent/ColorView.xaml

Line 472 in 99cf2f8

IsChecked="{TemplateBinding ColorModel, Converter={StaticResource EnumToBoolConverter}, ConverterParameter={x:Static controls:ColorModel.Rgba}, Mode=TwoWay}" />