Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
benstevens48 opened this issue Jan 29, 2024 · 2 comments
Labels
area-RadioButtons feature proposal New feature proposal team-Controls Issue for the Controls team

Comments

@benstevens48
Copy link

benstevens48 commented Jan 29, 2024

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 benstevens48 added the feature proposal New feature proposal label Jan 29, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Jan 29, 2024
Copy link

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.

@bpulliam bpulliam added team-Controls Issue for the Controls team and removed needs-triage Issue needs to be triaged by the area owners labels Feb 23, 2024
@JJBrychell
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-RadioButtons feature proposal New feature proposal team-Controls Issue for the Controls team
Projects
None yet
Development

No branches or pull requests

4 participants