Question: How to subclass AppBarButton without losing WinUI style?

[tipa]

In my apps I subclass AppBarButton in order to set the tooltip & property for screenreader to the same value as the AppBarButton's label:

public class AppBarButton : Windows.UI.Xaml.Controls.AppBarButton
{
    protected override void OnApplyTemplate()
    {
        base.OnApplyTemplate();
        AutomationProperties.SetName(this, Label);
        if (KeyboardAccelerators.Count == 0) { ToolTipService.SetToolTip(this, Label); }
    }
}

With WinUI 2.5 and before, I was able to set the correct styles to my subclass type like this:

<Style TargetType="MyAppBarButton" BasedOn="{StaticResource AppBarButtonRevealStyle}" />
<Style TargetType="MyAppBarToggleButton" BasedOn="{StaticResource AppBarToggleButtonRevealStyle}" />

No with WinUI 2.6, the default AppBarButton style changed and I tried to use this:

<Style TargetType="MyAppBarButton" BasedOn="{StaticResource DefaultAppBarButtonStyle}" />
<Style TargetType="MyAppBarToggleButton" BasedOn="{StaticResource DefaultAppBarToggleButtonStyle}" />

The problem is, that the style of the AppBarButton needs to be changed when it is placed in an overflow menu. This is done in the default CommandBar style here: https://github.com/microsoft/microsoft-ui-xaml/blob/main/dev/CommonStyles/CommandBar_themeresources.xaml#L960-L961

Now I thought, well this is quite tedious but I go ahead and try to copy & edit the whole DefaultCommandBarStyle and change those lines to

<Style TargetType="MyAppBarButton" BasedOn="{StaticResource AppBarButtonOverflowStyle}" />
<Style TargetType="MyAppBarToggleButton" BasedOn="{StaticResource AppBarToggleButtonOverflowStyle}" />

I put that edited style in a new file in my project and tried to compile it, but it resulted in errors:

1>C:\...\CommandBarResources.xaml(865,54): XamlCompiler error WMC0047: Element name 'OverflowContentRootClipTransform' is already used in this scope.
1>C:\...\CommandBarResources.xaml(870,38): XamlCompiler error WMC0047: Element name 'SecondaryItemsControl' is already used in this scope.
1>C:\...\CommandBarResources.xaml(850,42): XamlCompiler error WMC0047: Element name 'OverflowContentTransform' is already used in this scope.

How would I be able to resolve that error?
And why is subclassing a class (like AppBarButton) while keeping the default style so difficult in the first place?

[StephenLPeters]

I think that you've probably copied our template which includes some custom conditional xaml. You'll notice that OverflowContentRootClipTransform is infact defined twice in the template, once in the grid prefixed with Contract12Present and once in the grid prefixed with Contract12NotPresent. Winui2 does conditional xaml as a preprocessing step so the xaml complier never sees this, however your project will not have this version of conditional xaml. Contract 12 is the 21h1 version of windows, if you are targetting exclusively contract 12+ or contract 11- then you could just remove one of the grids from your copied template. If you are targetting more than that this will be difficult to do....

Ideally you could just override the resource named AppBarButtonOverflowStyle and AppBarToggleButtonOverflowStyle, however due to some.. quirks.. with how the resource system works and how Winui2 sits in the project structure these resources aren't actually overridable in their current state.

We could change https://github.com/microsoft/microsoft-ui-xaml/blob/main/dev/CommonStyles/CommandBar_themeresources.xaml#L960-L961 to reference these resources via a {ThemeResource} markup extension and then you would be able to override the resource at the page level, but not the application level, which I think it going to be the best solution, but wont be available until we perform the fix and do another release.

As for why this is so hard... its complicated. Winui2 is just a nuget package that sits on top of the framework and contains some new types and some styles for old types. Given this model, there is no way for us to specify that these new styles are the default styles for the controls in the system, since the default styles need to be included in the same package. So when you inherrit from a control you are changing the type which causes the non-default winui2 styles to not be applicable anymore, thus needing the based on style.

Then there is the issue of resource lookups which is also very complicated, but basically because all of these resources live in the same dictionary within the app.xaml's resources you have to be extremely percise with our your resources are set up for the lookup to find overrides.

Finally the conditional xaml the winui2 project utilizes was made because it is much more performant than traditional conditional xaml. It has the same syntax as the real conditional xaml, but we've needed to add new features that we needed for some of our types, which is why it does not function in your project when you copied it.

This is a real mess, but Winui3 will solve a lot of the issues...

[StephenLPeters]

#5540 this PR should allow you to override the resource with your own style, but I'm realizing now that might not even fix your issue, since the CommandBar style still specifies the wrong target type, even if you change the based on style...

[tipa]

Thanks for the detailed explanation.
It is very unfortunate that such a seemingly small requirement (setting the tooltip to the same value as the Buttons Label) not only causes me to deal with default XAML styles, but actually doesn't seem to be possible with my idea of subclassing the AppBarButton class. Especially because it was doable with previous WinUI versions but now stopped working with v2.6.

This is a real mess, but Winui3 will solve a lot of the issues...

It is a mess, and from what I read noone knows when WinUI3 support for UWP will happen, or if it will happen at all...

Coming back to my original problem: How would I ideally do some AppBarButton initialization (the code that I currently have in the OnApplyTemplate, see my first post)? Only thing that comes to my mind is having a Loaded event handler on all AppBarButtons to do the initialization. Needless to say that would be some very ugly code which needs to be duplicated throughout my app in every page with a CommandBar (and there are many of them in my app)…

[eugenegff]

Just got this issue with my descendant of AppBarToggleButton while upgrading to Win11-like styles from WinUI 2.7.
I think it should be possible to catch changes of IsInOverflow property and emulate effect of AppBarToggleButtonOverflowStyle, i.e. HorizontalAlignment=Stretch, Width=NaN

P.S.
Unfortunately, IsInOverflow is not set for dynamic overflow buttons, will try to catch changes in visual state.

[eugenegff]

Working solution for the problem:

// descendants of the AppBar[Toggle]Button broke mechanism of switching to AppBar[Toggle]ButtonOverflowStyle, and need to emulate it
void fixOverflowStyle(Primitives::ButtonBase^ appBarButton)
{
	FrameworkElement^ layoutRoot = safe_cast<FrameworkElement^>(Media::VisualTreeHelper::GetChild(appBarButton, 0));
	auto vsgs = VisualStateManager::GetVisualStateGroups(layoutRoot);
	for (VisualStateGroup^ vsg : vsgs)
		if (vsg->Name == "ApplicationViewStates")
		{
			vsg->CurrentStateChanged += ref new VisualStateChangedEventHandler(ref new VisualStateChangedEventHandler([weakButton = WeakReference(appBarButton)](Object^ sender, VisualStateChangedEventArgs^ e)
			{
				if (auto _this = weakButton.Resolve<Primitives::ButtonBase>())
				{
					if (e->NewState->Name == "Overflow" || e->NewState->Name == "OverflowWithMenuIcons")
					{
						_this->HorizontalAlignment = ::HorizontalAlignment::Stretch;
						_this->Width = std::nan("");
					}
					else
					{
						_this->ClearValue(FrameworkElement::HorizontalAlignmentProperty);
						_this->ClearValue(FrameworkElement::WidthProperty);
					}
				}
			}));
		}
}

void MyAppBarButton::OnApplyTemplate()
{
	fixOverflowStyle(this);
	__super::OnApplyTemplate();
}

void MyAppBarToggleButton::OnApplyTemplate()
{
	fixOverflowStyle(this);
	__super::OnApplyTemplate();
}

P.S. Unfortunately, visual states are not changed for AppBar[Toggle]Button descendants that are in overflow menu due to the dynamic overflow, only for statically SecondaryCommands.