microsoft-ui-xaml icon indicating copy to clipboard operation
microsoft-ui-xaml copied to clipboard

Proposal: RadioButton GroupName should allow scoping to the same scope as x:Name

Open benstevens48 opened this issue 1 year ago • 1 comments

Proposal: RadioButton GroupName should allow scoping to the same scope as x:Name

Summary/Rationale

Currently, RadioButton GroupName is scoped to the entire visual tree, and not just the same scope as x:Name (such as within a UserControl). This is extremely counter-intuitive and is almost never the desired behavior. In HTML, a radio button group (using the name attribute) is scoped to the form it is contained in. In XAML, especially given that x:Name is scoped and not global (unlike HTML id), one would expect the RadioButton GroupName to have the same scope as x:Name by default. The current default behavior leads to delayed bugs in applications e.g. once you start adding more than one copy of a UserControl containing RadioButtton controls with a certain group name to the page, you get the seemingly inexplicable behavior of the radio buttons becoming unchecked unexpectedly, and it takes ages to realise that this due to the global scope of GroupName. Every developer has to go through this painful process, and then use a workaround of setting the GroupName to a unique runtime-generated value (e.g. new Guid).

Scope

Capability Priority
There must be a way to ensure RadioButton controls can be given a GroupName that has the same scope as x:Name Must

Open Questions

The exact API is open to question.

I propose a new property called ScopedGroupName which is the same as GroupName except that it has the same scope as x:Name.

An alternative would be to have another property, settable via a style, that can change the scoping behavior of GroupName, something like a boolean IsGroupNameScoped or GroupNameScope with an enum value.

A final alternative would be to make the breaking change such that GroupName is always scoped the same as x:Name. However, this may break existing applications if they are relying on the current behavior, and it may very occasionally be useful to have GroupName scoped to the whole visual tree, although this seems like bad practice to me.

benstevens48 avatar Jan 29 '24 18:01 benstevens48

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

github-actions[bot] avatar Jan 29 '24 18:01 github-actions[bot]

Unfortunately, the proposed solution will not work because the name scope it much more granular from a xaml point of view than necessarily from an application's. For example, imagine a radio button in a list that contains a template with multiple levels of controls and then the Xaml control itself. These can all be in different name scopes.

As an alternative, I would propose adding an attached RadioButton property that can be used to identify the hierarchical scope. For example:

<UserControl x:Name="MyControl" RadioButton.NamedGroupScope="true"/>

I am not sure this is perfect and will need some additional vetting before we settle on it.

JJBrychell avatar Mar 19 '24 01:03 JJBrychell