Showing more stuff on Windows 8.1 tablets and laptops

I recently discovered a great feature of new Windows 8.1 Modern UI, that enables owners of high resolution tablets and laptops to display much more content at once (for the price of making things smaller).

Microsoft Surface Pro 2 with Full HD display will by default show the Start Screen in a fashion similar to this: startscreennormal

As you can see I get four rows of medium sized tiles. Also in normal setup, the device is capable of showing at most two Windows Store apps at once with multitasking.

Now let’s try to tune it up a little!
Continue reading “Showing more stuff on Windows 8.1 tablets and laptops”

ItemsSource and SelectedItem

Quite a common mistake that XAML developers do here and there (especially myself, I just can’t stop causing this bug…) is to switch the order the ItemsSource and SelectedItem properties in XAML while building a MVVM pattern based app.

Let’s see it in context the WinRT ListView control. To bind some items to it we use the ItemsSource dependency property. To select one of them we bind to SelectedItem.

Looks great right? Not yet.

XAML parser processes the file in the left right order. This way the first dependency property it faces is the SelectedItem. Here it tries to select the item in the collection, but unfortunately, it cannot be found. In that moment the SelectedItem of the ListView is actually set back to null. Now the ItemsSource is reached normally, but it is too late to get the SelectedItem back “from the dead”.

The correct order only when SelectedItem is placed behind the ItemsSource. Then we get the desired results and will no longer get unexpected, hard to decode behavior.

 The devil is in the details.

Localization in WinRT not working?

This week I had to deal with very strange behavior when trying to localize a Windows 8.1 app in Czech and English.

As always, I prepared a special localization class, added the *.resw files for en and cs and finally hooked it all up to XAML via binding. Everything seemed hunky-dory except for the tiny fact that only English (language neutral) variant of the app was functional. The situation got even stranger when I replicated the exact same set-up in a new project and it worked normally.

After a longer search I found the hidden cause of the problem.
The Package.appmanifest file, that stores different package-related settings of the resulting Windows 8.1 app package has numerous options, that are not available directly via the designer. In fact, the AppManifest file is just a XML file with a fancy extension, that can be edited directly. In Visual Studio 2013 click the right mouse button on this file and select the Open With… or View Code command.

Opening Package.appmanifest in XML editor

The source of my problems was one of the elements in manifest file – element Resources to be exact. This element influences the behavior of resource files in the project and more importantly its contents describe which languages the app supports. In my case it contained just one – the english variant:

To support other languages, I would have to repeat the Resource element with other ISO codes of languages I need. This would be too much of a burden and not very practical. A better solution is the form that is actually set as default in newly created Windows 8.1 projects:

Special constant x-generate specifies, that while the package is constructed, the required localizations are automatically generated on the basis of what language *.resw are present in the project.