You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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
Open Questions
The exact API is open to question.
I propose a new property called
ScopedGroupName
which is the same asGroupName
except that it has the same scope asx: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
orGroupNameScope
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.
The text was updated successfully, but these errors were encountered: