The x:Name attribute in XAML creates named fields that you can use to access the controls from the code-behind. However, as opposed to WPF, in UWP these fields are private which means you can access them from the code-behind only, not from other classes. While noting it is a good idea from architectural standpoint, is it possible to change this behavior? Continue reading “Modifying XAML named field visibility”

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?).

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.

On the left is the animation from “Transparent” to White, on the right from “Transparent” to Black

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. BecauseMvvmCross 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?

Universal Windows Platform runs on many different device families. To make the app look great on different devices, we can usually use AdaptiveTriggers, which react to different screen sizes. But if we require even more specificity, we can create a device family-based state trigger. Continue reading “Device family state trigger in UWP”

The UWP ListView and ListBox controls can be used to present lists of items in the user interface. By default the items are left-aligned and take up just the space they require, which is unfortunate if you want to stretch them to the full available width of the list control. How to achieve that?

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
CommandBaropens 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
...OpenDownvisual 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