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:
Child node "2" exited prematurely. Shutting down.
Diagnostic information may be found in files in the
temporary files directory named MSBuild_*.failure.txt.
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.
The Universal Windows Platform CommandBar control has a new feature called dynamic overflow since the Anniversary Update. This automatically adjusts the number of presented app bar buttons so that they fit and puts the additional commands in the secondary (overflow) menu. This addition has however inadvertently caused some headaches for developers who use
Content property of the
CommandBar to display additional content – it turns out, that alignment of the content now doesn’t work properly.
Let’s demonstrate the issue with a simple example.
<AppBarButton Icon="Accept" />
<TextBlock Text="My content" />
We would expect, that the content of the
CommandBar is aligned to the center of its available area, which indeed was the case before the Anniversary Update.
Since Anniversary 14393 SDK, the
HorizontalContentAlignment property is by default not respected.
Cause of the problem
The default control templates are stored in a XAML resource dictionary file on the following path:
C:\Program Files (x86)\Windows Kits\10\DesignTime\CommonConfiguration\Neutral\UAP\10.0.14393.0\Generic\generic.xaml . If you search for the
CommandBar template inside this file, you will find out that it contains a new
As you can see, when dynamic overflow is enabled, sizing of the columns in the main layout
Grid of the control changes.
In the default visual state (
DynamicOverflowDisabled ) is the
ContentControlColumnDefinition.Width set to
* (star) and the
PrimaryItemsControlColumnDefinition.Width set to
Auto . This means that the app bar buttons on the right take up a certain width and the remaining space is dedicated to the content.
With dynamic overflow enabled, sizing of the columns is flipped. The control lets the primary items column take up as much space as it can (so that the available space can be used for the buttons and the number of displayable buttons can be calculated at runtime) and the content column now gets only the width it actually needs. Whichever alignment you set to the content doesn’t matter. The content will always seem left aligned, because its column is sized just to fit.
Since the Anniversary Update, dynamic overflow of the command bar is enabled by default.
You can disable dynamic overflow using the
IsDynamicOverflowEnabledproperty. Although you have to make sure that the app bar buttons display well on all display sizes, you can also align the content as you please.
If you want to preserve the dynamic overflow feature, you may just want to put some margin around your content to make sure it looks aligned. Of course, to support multiple different display sizes, you should adjust the margins using Adaptive Triggers.
Although the default Windows 10 font – Segoe UI – is certainly very beautiful, you might sometimes want to give your Universal Windows Platform app a bit of uniqueness and personality using a custom font.
Getting a font
Firstly find a custom font you want to use. There are many fonts you can use for free (even in commercial projects), as well as many fonts you can purchase.
After you choose the font you like, download its .ttf or .otf file and add it into your UWP app project as a Content file.
Setting the font in XAML
Each text control in XAML has a FontFamily property, which you can use to set the font. For the preinstalled fonts it is sufficient to just use the font name itself. For custom fonts we have to be more specific:
[FontFilePath] is the relative path to the font file in the project. In case you have an ArimaMadurai-Black.ttf font in the Assets/Fonts folder of your project, you will use /Assets/Fonts/ArimaMadurai-Black.ttf as the path.
[FontName] is the name of the font. Here things are a little tricky. Some fonts require the font name to include the type suffix (font weight, italics) and some don’t. You might need to use trial end error to find out which form is requested. The XAML designer should reflect the change immediately.
There is an alternative to manually setting the font family in XAML – using the XAML properties window. Select a text-based control and then expand the Text settings group in the property manager. Using the font dropdown, you can select not only from the installed fonts, but also from the custom fonts you have added into your project (these should be on top of the list).
Note that the properties window always adds the font type suffix to the FontFamily value. In case the font doesn’t display correctly when you apply the setting, remove the font type manually.
Setting font family in code
Changing the font family in code is as easy as creating an instance of the Windows.UI.Xaml.Media.FontFamily class with the same value as in XAML passed to the constructor.
Windows 10 added XAML integration of DirectWrite downloadablefonts. With this feature you can set the font family of your text controls to a font that is not currently installed on the device and DirectWrite will download the font on-demand in the background. Before the font is downloaded, a fallback font will be displayed instead. Also, it should be able to download just the portions of the font that you need, which is beneficial for large fonts that support languages like Chinese, Japanese or Korean. The downloaded fonts are stored in a system font cache, so that they can be reused by any app.