RadioButton is broken

[benstevens48]

I know there is now a RadioButtons control, but this is about using multiple RadioButton controls, which is still necessary to support certain layouts (e.g. RadioButton controls in a WrapPanel).

Bug 1 - can't set IsChecked in XAML
Consider the following XAML.

     <StackPanel>
            <StackPanel BorderBrush="Black" BorderThickness="1">
                <RadioButton Content="Radio button 1" IsChecked="True"></RadioButton>
                <RadioButton Content="Radio button 2"></RadioButton>
                <RadioButton Content="Radio button 3"></RadioButton>
            </StackPanel>
            <StackPanel BorderBrush="Black" BorderThickness="1">
                <RadioButton Content="Radio button 1"></RadioButton>
                <RadioButton Content="Radio button 2"></RadioButton>
                <RadioButton Content="Radio button 3" IsChecked="True"></RadioButton>
            </StackPanel>
        </StackPanel>

RadioButton controls without a GroupName are scoped to their parent, thus this should produce two independent sets of radio buttons. Want to guess what it initially looks like when you load a page containing this markup? Only the final radio button is checked. The first one is not checked. It appears that the radio buttons are put into their respective groups after the IsChecked property is set in XAML. Note the the radio buttons do subsequently work as two separate groups. The workaround is that you have to set IsChecked in code behind after the InitializeComponent of the page, which is annoying.

Bug 2 - GroupName is scope to the entire visual tree rather than the naming container
I'm not sure if naming container is the right word - I think this is what it was called at some point, but maybe it's now called definition scope or something like that. Suppose you create a set of radio buttons inside a UserControl, like this.

<UserControl x:Class="App2.MyUserControl2" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="using:App2">
    <Grid>
        <StackPanel BorderBrush="Black" BorderThickness="1">
            <RadioButton Content="Radio button 1" GroupName="UserControlRadios"></RadioButton>
            <RadioButton Content="Radio button 2" GroupName="UserControlRadios"></RadioButton>
            <RadioButton Content="Radio button 3" GroupName="UserControlRadios"></RadioButton>
        </StackPanel>
    </Grid>
</UserControl>

Suppose you use two copies of the UserControl in your main page, like this.

        <StackPanel>
            <local:MyUserControl2></local:MyUserControl2>
            <local:MyUserControl2></local:MyUserControl2>
        </StackPanel>

How do you think the radio buttons will behave? You'd think you'd get two independent sets of 3 radio buttons. In fact, you will get a single set of 6 radio buttons. Now it's possible this behavior is deliberate, but I really don't think so - would anyone really expect it to work like this? This effectively makes setting the GroupName property to a fixed value useless. The workaround is to create a new GUID after InitializeComponent in the user control, and then to set the GroupName of all the radio buttons to that, and then set the IsChecked property of the one you want. Technically, fixing this so the GroupName is scoped to the current naming container or definition scope or whatever it's called, would be a breaking change. If you think people are really relying on the existing behavior (which I find extremely unlikely), then please consider adding a ScopedGroupName property to RadioButton which is scoped to the current naming container.

These bugs make working with RadioButton controls very awkward (and these bugs have been there from the beginning - I did report them on UserVoice in the past but that didn't get any attention).

Windows 10 version	Saw the problem?
November 2019 Update (18363)	Yes

Device form factor	Saw the problem?
Desktop	Yes

[marcelwgn]

Those seem to valid issues.

If the only reason RadioButtons is not issue is the fact you can't change the layout, you might want to retemplate the RadioButtons control and use a different layout internally.

We might want also want to make the layout of the internal ItemsRepeater a property, so that does not require retemplating.

[ranjeshj]

@YuliKl @StephenLPeters as FYI. Exposing the Layout property on RadioButtons is an option.

[marcelwgn]

@ranjeshj Should we open a proposal for that (adding a layout property to RadioButtons)?

[ranjeshj]

@ranjeshj Should we open a proposal for that (adding a layout property to RadioButtons)?

Yes. Please.

[benstevens48]

Thanks for the comments. This issue was intended to be mainly about fixing bugs with the individual RadioButton control - I hope it can stay focused on that. I think there will always be situations (possibly quite rare) where individual RadioButton controls have to be used, and since frameworks like HTML have this control, I think it should continue to be supported.

Regarding the comments about the WinUI RadioButtons control. In my case I have RadioButton controls inside a custom WrapPanel control. If it the RadioButtons template was happy with an ItemsControl replacing the ItemsRepeater, then I could re-template it to make use of my custom WrapPanel, using it as the ItemsPanel in the ItemsControl. (I haven't tested whether this works or not). Exposing the Layout property would be another solution, but then I'd have to refactor the layout logic of my control so that I could be used as the Layout property, which would be a bit awkward.

[ranjeshj]

@benstevens48 Yes. I am following up to understand the issues with RadioButton. I believe one of the reasons for the RadioButtons control in the first place is because of the automation experience when using GroupName. RadioButtons provides a better automation experience (Narrator) for that scenario.

ItemsRepeater and ItemsControl do similar things, so if you are writing a custom WrapPanel, it is possible to do the same for WrapLayout (deriving from NonVirtualizingLayout). There is also a LayoutPanel in the preview which can get you the same behavior of WrapPanel (LayoutPanel has a Layout property that you can feed in the same layout object).

[StephenLPeters]

Unfortunately these RadioButton issues won't be able to be fixed without winui 3.

[StephenLPeters]

@benstevens48 Since we will not be able to fix these issues for a while, you might be able to work around this issue by setting the checked radio button from code behind in the on apply template callback.

[benstevens48]

Thanks, yes I have already been using this workaround (setting after InitializeComponent) for several years, I just wanted to report it so that hopefully it can get fixed eventually.

[StephenLPeters]

Thank you for that! I think this is the same bug as #1299 but this one has more info so I'm going to close the other as a dupe.

[robloo]

I ran across this one too. Needs to be addressed ASAP. Radio buttons with implicit groups are broken for use in flyouts and controls. These types of bugs are a real pain with UWP and need to be addressed quickly in WinUI 3.0 if it isn't going to suffer the same fate.

[benstevens48]

Has this been addressed in WinUI3 yet? Would also be good to fix it in system XAML.

[JJBrychell]

It looks like we are going to be able to address the first item in this issue where setting the radio button IsChecked in Xaml markup was getting lost. This was happening because when the initial "IsChecked" value is set during load of the markup, it has not yet been added to the Xaml tree, consequently, it goes into a group with a null parent. Every radio button on the page follows this same pattern so as far as the framework is concerned, they are all in the same group so only the last "isChecked" is retained. We have a change working through the process that will delay this evaluation until the radio button is actually added to the tree so the proper parent can be determined.

The second item is more complex because depending on the needs of the application we can see both behaviors being desirable. Plus to change the behavior would be a breaking change. And the proposed API seems like it might be confusing as we would have multiple properties doing the same thing in most scenarios. And finally, WPF does not support his behavior, which all goes to making this item much more of a feature request and probably something we are not going to get to in the near future.

However, if you feel strongly about this (and I can see the advantages of it), it might be helpful to split this off into an actual feature requested and attempt to get community support to rally around it to get it added to our priority list.

[benstevens48]

OK I've added a feature proposal here - #9297

[JJBrychell]

The issue with being able to set checked boxes in Xaml has been addressed and is scheduled for the next preview release of 1.6.

We also spent a fair amount of time trying to provide a solution to the second issue but were able to come up with one that didn't have a significant breaking change or require a new api, which we couldn't come up with clean definition for. I think ultimately the correct approach will be to require the explicit specification of a radio button container (e.g. a RadioButton.IsGroupNameScope="true") attached property. But if we tackle this, it will be down the road and we can track with the feature proposal.