Quick tip: Always implement all VisualStates!

I have come across an interesting oddity while building a UWP app.

XAML VisualStates define the visual look of control in different states. Even though you sometimes don’t need to make distinction for all of them, you should still implement them however (even if they are just a simple copy-paste of another style) or you might meet some inexplicable problems.

In my case I have customized the ListViewItem  style and forgot to include implementations for the PointerOverSelected  and PressedSelected  states. Surprisingly everything worked as expected on my devices, as the visual used the Selected  state as fallback. However, I have later found out the same did not happen on other devices and the list view items stayed in the PointerOver state until the mouse cursor moved away (which also makes sense).

This difference in behavior is especially interesting, as the problem did not originally occur on the stable builds of Windows 10 Creators Update, but now it seems to occur as well (maybe after some patches?).

Resource behavior inconsistency for ItemTemplates of list controls in Anniversary Update

It appears that the Anniversary Update has a hidden buggy behavior concerning Resources in ItemTemplates of list controls. I have hit this problem while working on an UWP app and I will describe the problem along with a workaround, which you can use to make sure your app will behave correctly on all versions of Windows 10. Continue reading “Resource behavior inconsistency for ItemTemplates of list controls in Anniversary Update”

When a single transparent color is simply not enough

There are countless times in the life of a Universal Windows Platform app developer when the “Transparent” color comes handy. However, it is good to remember that “Transparent” is still just a color, otherwise you can encounter some unwelcome surprises.

Animation of "Transparent" color
On the left is the animation from “Transparent” to White, on the right from “Transparent” to Black

Continue reading “When a single transparent color is simply not enough”

Modifying UWP navigation backstack with MvvmCross

While developing mobile apps, you may encounter the need to clear or pop the navigation stack to remove specific pages from appearing when the user navigates back. Because MvvmCross framework has a lot of abstractions above the target operating systems, it does not contain a built-in mechanism to manipulate the back stack. How can we use the framework capabilities to implement this requirement in a clean fashion?

Continue reading “Modifying UWP navigation backstack with MvvmCross”

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.

Problem

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 .

Solution

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.

Summary

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.