Repository navigation
Too hard to change resource values. #863
Description
I'll illustrate this with a specific example, but it is a broad problem.
I tried to change the SizerBaseBackgroundPointerOver brush that is used in the SizerBase control template, and found it to be almost impossible to do.
The only way to do it seems to be to make a copy of the DefaultSizerBaseStyle, rename it and rename the ThemeResources that it uses, such as SizerBaseBackgroundPointerOver. Obviously this is bad from a maintenance point of view.
Notably, it is not sufficient to just merge <ResourceDictionary Source="ms-appx:///CommunityToolkit.WinUI.Controls.Sizers/SizerBase.xaml" /> into your ResourceDictionary and redefine the SizerBaseBackgroundPointerOver brush, even if you then copy in the DefaultSizerBaseStyle -- you have to also change the name of the SizerBaseBackgroundPointerOver brush within that style. It seems that resource resolution is scoped to the dictionary that defines the template (the CommunityToolkit dictionary), not to the dictionary where the style is redefined.
There really should be an easier way to do it. It is very surprising that one cannot change the default colors or other style constants anywhere in the Toolkit!
Activity
lgztx96 commentedon Jun 30, 2026
If you only want to override the brush value, copying
DefaultSizerBaseStylemay not be necessary.For example, overriding the resource locally on the control works:
In my testing, this correctly overrides
SizerBaseBackgroundPointerOverwithout copying the default style or renaming any resource keys.sjb-sjb commentedon Aug 9, 2026
@lgztx96 I like this, but what I am trying to do is define a style that applies the color, rather than have to do this on each instance of the control. Any suggestions for that?
@olga-io-92 I think that what you suggest is what @lgztx96 demonstrates, correct?
darlcydney26 commentedon Aug 19, 2026
It seems like the scoping issue with resource resolution in the SizerBase template is indeed a significant hurdle. Have you considered using a custom style selector that targets the SizerBase control specifically? This way, you can define a style that sets the SizerBaseBackgroundPointerOver brush while keeping the rest of the default styles intact. Implementing a new style in your application resources with a higher precedence could allow for more flexibility without duplicating the entire DefaultSizerBaseStyle.
sjb-sjb commentedon Aug 20, 2026
@darlcydney26 I don't really understand what you are describing, can you show an example?
@chalynseattle Would that mean redefining the DefaultSizerBaseStyle in my resource dictionary? If so then that's what I'm trying to avoid.
jonahwhite115 commentedon Sep 22, 2026
Since WinUI resolves theme resources by looking at the application-level theme dictionaries first, overriding `SizerBaseBackground
carlinshree commentedon Sep 27, 2026
The underlying issue is that the control template uses StaticResource lookups that are baked into the assembly-level ResourceDictionary, effectively pinning the resolution scope to the Toolkit's internal dictionary rather than the application's merged dictionaries. Could we refactor these specific brushes to use ThemeResource instead, which would allow the runtime to perform a dynamic lookup across the MergedDictionaries chain?
sjb-sjb commentedon Sep 27, 2026
@carlinshree this sounds like a good approach, assuming it tests correctly as envisioned. It also addresses the fact that differing colours are needed for light and dark themes.
One thing I would point out is this goes across the entire toolkit. When would we ever leave a resource as static / not-user-changeable ?
emmettmorin commentedon Sep 30, 2026
The resource scoping issue occurs because the control template hardcodes the reference to
SizerBaseBackgroundPointerOverwithin theCommunityToolkitdictionary, effectively pinning it to the library's internal resource lookup scope. Would exposing the brush as a public property or a TemplateBinding on theSizerBasecontrol itself resolve the need to copy the entireDefaultSizerBaseStyle?sjb-sjb commentedon Oct 1, 2026
@emmettmorin I think that exposing the brush as a public property would work, but keep in mind that this issue goes for all resources defined in the toolkit. So that would be a lot of properties to add, tantamount to overthrowing the XAML resource libraries paradigm. There is something to be said for doing that, but ...
I'm not sure how the TemplateBinding would work, if you try this and it works then please let me know. Again same comment about it applying across the Toolkit.
edinakama commentedon Oct 3, 2026
The issue is that the template uses
StaticResourcelookups that are baked into theCommunityToolkit.WinUI.Controls.Sizersresource dictionary at compile time, so have you tried checking if exposing these brushes asTemplateBindingproperties on theSizerBasecontrol allows for local overrides without needing to redefine the entireDefaultSizerBaseStyle?sjb-sjb commentedon Oct 5, 2026
Hi @edinakama
How would I do that without copying over (or deriving from) the source code of the SizerBase control to define the local properties, and also creating a new template for it that applies the local properties into the template? Or if that is the approach you have in mind, how would it be any better than just redefining the template? Again, going across the whole toolkit with this issue.
sjb-sjb commentedon Oct 5, 2026
It seems to me that a new standard approach needs to be adopted for defining toolkit resources in such a way that end users can redefine the brushes and sizes. Then that standard approach needs to be applied backwards across the toolkit.