The curious case of jumping app bar button labels

Most UWP apps can benefit from using the CommandBar control to present easily accessible commands to the user. Unfortunately the control sometimes behaves unexpectedly. Two of these surprising problems are addressed in this article.

Left-side commands

By default, CommandBar is designed to stack commands on the right side of the control. This allows easy overflow in case screen size is too small (DynamicOverflow feature introduced in Anniversary Update). Sometimes you might want to display commands on the left side of the control as well (for example a global command or a special action. Command bar is a content control and its Content property defines what should be displayed on the left. We can declare any markup here, but in this case we want to use AppBarButton controls. Example of this might be the following:

When we launch the application, we see the first problem immediately – the app bar button label is clearly sticking out from the bottom of the bar.

Labels sticking out
Labels sticking out

The reason is simple – the default layout of the app bar button is designed like this – the label is just situated in this position. When the button is part of normal PrimaryCommands collection of CommandBar, the control itself ensures to hide the label when the command bar is in normal state and display it only when it is expanded. It is quite easy to mimic this behavior by binding the IsCompact property of the AppBarButtons to the inverse of the command bar’s IsOpen property.

The InverseConverter is a simple IValueConverter that negates the provided boolean value.

Labels jumping all around (and disappearing)

The left commands now look and feel great and all seems rosy. At least in most cases. Not always! In about one try out of ten, you will encounter labels of app bar buttons displaying on the right side of the control or even not being present at all!

When label business goes wrong
When label business goes wrong

This is very curious and it took me a while to dig out a reason and solution for this. After some searching around I stumbled upon a Stack Overflow answer by Microsoft’s Jay Zuo, addressing exactly this problem.

The Anniversary update of Windows 10 introduced a new LabelPosition property, which determines where the label should be displayed. In the default state, it looks up to the parent (which should be a command bar) and checks the DefaultLabelPosition property, which can be Bottom, Right or Collapsed . This process works great when the app bar buttons are inside the PrimaryCommands collection of CommandBar, but when they are embedded inside a different control, like a StackPanel, they tend to do whatever they want randomly.

Solution requires us to edit the default app bar button style and comment out the visual states for Right and Collapsed placement, including a related resource:

Source code

Example source code for this article is available on my GitHub.


CommandBar is quite customizable, but using it in ways it was not directly designed for may lead to unexpected and unpredictable results. These situations can be resolved using straightforward workarounds, but we must still be aware of them while building your app.

Buy me a coffeeBuy me a coffee

1 thought on “The curious case of jumping app bar button labels”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">


This site uses Akismet to reduce spam. Learn how your comment data is processed.