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