Forcing the CommandBar to open down

The CommandBar  control is a vital component of UWP app design. It is an evolution of the AppBar  concept, which was available ever since Windows Phone 7, but with UWP is much more feature complete. One thing that is still missing however is the option to choose the direction in which the command bar opens.


The default behavior of the CommandBar  is to open in the up direction whenever the control is not at the very top of the window. This is an issue, because this holds true even when we define a custom title bar on Desktop, in which case the CommandBar  opens below the window’s minimize, maximize and close buttons which doesn’t look good at all.

The default template

The default template of the CommandBar  control defines the states of the control as a collection of VisualStates  and VisualStateTransitions . It turns out that there is always a separate visual state for down and up direction.

Inside these states you can see that the system just uses different values for some of the properties like CommandBarTemplateSettings.ContentHeight  vs CommandBarTemplateSettings.NegativeOverflowContentHeight  for the Y  property of OverflowContentRootTransform .


We cannot easily change the inner logic of the control itself, but we can make the control in up-open state look identical as it does for down-open state. This can be achieved purely by copy-pasting the Storyboards  from ...OpenDown visual states and visual state transitions to the respective ...OpenUp  counterparts. Unfortunately the manual copy-pasting is the only option, because extracting the Storyboards  into separate resources and referencing them with {StaticResource} isn’t supported.

To get a full copy of the default control style you can use either the XAML Designer (right-click the control, select Edit Template and Edit a Copy…), or search for it in C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP{version}\Generic\generic.xaml

To spare your Ctrl , C  and V  keys, I have prepared the full modified style which you can take and use in your app. You can get this style here on my GitHub along with the full sample project for this article. Beware that this style targets the Anniversary Update. I recommend doing the changes manually if you target a different version.


The CommandBar  is a great control that works as we expect most of the time. When we hit an issue however, its template is quite easy to modify.

How to add new preview devices to the XAML Designer

The Visual Studio XAML Designer for Universal Windows Platform offers design-time device previews for several different screens size and scaling combos. Unfortunately, the default selection might not be sufficient for you in some cases, especially when you want to optimize for a specific screen. Is it possible to expand the selection with more devices?

Default device offering in Visual Studio

Continue reading “How to add new preview devices to the XAML Designer”

Tip: Curly brackets in XAML Binding’s ConverterParameter

While working on an UWP app, I wanted to create a string.Format  based value converter, so that I could provide a format string in the ConverterParameter , augment the data bound value with it and use the result as a key for a localized string from resources. When I tried to build the project however, I was met with the following cryptic error message:

Although the nor the error nor the generated diagnostic were too helpful, because I have mostly added just the new XAML binding, I suspected the error must be hidden there.

As you might expect, it is not possible to use curly brackets directly inside the XAML binding expression.

Solution is simple – escaping with backslash.

With this little change, the code will compile and the value converter works as expected.

Adding Hyper-V-less boot entry with PowerShell

Developers often encounter the need to run virtual machines using VirtualBox and Hyper-V-based mobile emulators on the same machine (for example Windows Mobile or Visual Studio Android Emulator). Unfortunately only one of the two can be enabled at once. The easiest solution is to create two boot entries and disable Hyper-V in one of them.

CMD way

The awesome Scott Hanselman provided a quick command line solution in one of his blogposts.

As part of creating a Chocolatey based PowerShell install script for my most used tools after computer reinstall, I wanted to make this automatic and preferably skip the copy-paste step.

PowerShell script

The script is very simple:

First line of the script runs the bcdedit  tool and create a copy of the current boot entry. The result is a string in the following form:

We need to parse out the identifier enclosed between curly brackets. This is just the job for regular expressions on the second line of the script. The matches are stored in the   $matches  variable.

Finally we can use the identifier to modify the boot entry to disable Hyper-V on the third line.

And that’s it! Pretty simple but convenient. You can simply run the script and the new Hyper-V-less boot entry will be created for you automatically. Be sure to run the script with administrator permissions.

You can download the script here.