UWP apps should work great with any kind of input including the keyboard. That includes support for keyboard shortcuts and checking for the state the keys are in. It turns out however that there are some things we have to watch out for. Continue reading “The right way to check for key state in UWP apps”
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”
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?).
The new Visual Studio 2017 comes with support for a new PackageReference package management format, which replaces the old Packages.config and project.json formats and puts the package references directly in the project file.This is bound to be the standard for NuGet in the future (or the one NuGet standard to rule them all, as they say 🙂 ), but is not supported in older versions of Visual Studio. Depending on your scenario, you might want to choose the appropriate package management format that suits your needs. Luckily, Visual Studio offers you this option via a new setting. Continue reading “Choosing NuGet package management format for new projects”
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”
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.
Soon after the release of Visual Studio 2017, the Visual Studio Team Services team has added a Hosted VS2017 build agent that has support for all the latest and greatest technologies. Unfortunately although the build task with Visual Studio 2017 is itself present, the newest version of NuGet wasn’t added, yet. Fortunately, it is possible to use a custom nuget.exe to circumvent this issue and be able to restore packages for project using the new csproj format with <PackageReference>. Continue reading “Using custom nuget.exe in VSTS build process”
Localization is fun when it works, but pain when it does not. I have experienced this pain first hand in the form of cryptic MissingManifestResourceException errors and want to share with you when they can occur and also to have a reminder if I hit this problem again. Continue reading “Localization gotcha: MissingManifestResourceException”
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”