Tip: Curly brackets in XAML Binding’s ConverterParameter

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:

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.

As you might expect, it is not possible to use curly brackets directly inside the XAML binding expression.

Solution is simple – escaping with backslash.

With this little change, the code will compile and the value converter works as expected.

How to show touch keyboard on touch interaction with WPF TextBoxes

Updated November 2016 – .NET Framework 4.6.2

Windows Presentation Foundation (WPF) apps have a bit harder life in the touch-enabled world. In WinRT apps, the touch keyboard shows up automatically when a text field gets focus so that the user can type without the need of a classic keyboard (no interrupting of her touch workflow). For classic desktop apps the situation differs – TextBoxes don’t cause the touch keyboard to appear and the user has to open it manually. That is obviously very cumbersome.

Hey! How can I get you to my WPF app?

There are two different workarounds for this problem.

The hack-y way

The first solution is quite a bit of hacking. This requires us to turn off the inking support for our WPF app and actually force the system to behave the right way. You will need some COM import and call native Windows API. This process is extremely well described here on Brian Lagunas’ blog and I encourage you to try it out. If it works for you, great!

The disadvantage of this solution, that I discovered, is that it interferes with touch “panning” of ListBox controls. Any try to do touch panning only fires ItemClick events on the hovered items and the user needs to scroll using the small scroll bar and that is more than inconvenient.

The simple, but more manual way

To overcome the issues that come after disabling inking support in your WPF app, we can go with a simpler but less automatic solution. We will extend the TextBox control and change its behavior when it gets touch focus.

So how does this work?

When the TextBox receives focus after the user enters it with touch, the GotTouchCapture event is called. In this event we can manually start up the process of touch keyboard. The touch keyboard is just a classic desktop application that lives on the path “C:\Program Files\Common Files\Microsoft Shared\Ink\TabTip.exe”.

This solution is very simple and doesn’t require any “hacking” per-se. The only disadvantage is that you as the developer have to ensure, that you use this modified version of TextBox control every time you need to get the right touch-based behavior.

Killing the process

A logical extension to this is to kill the touch keyboard process when it is no longer needed – the input loses focus. The Process.Start( string ) method returns an instance of Process class which provides a Kill() method that will terminate the process when called.

First we need to store the process instance in a private field of the TextBox:

Now we wire up the LostFocus event:


Update – Windows 10 way

In Windows 10, this becomes much less of a problem thanks to the new Tablet mode and settings.

Tablet mode

tablet-modeThe newest version of Windows brings a new mode called Tablet mode, which can be turned on via the Action center or in Settings app, and which is optimized for touch first usage. While some see the way it works as a downgrade opposed to Windows 8.1, it presents much more inuitive integration of both new Windows Store apps and classic desktop applications. Each app defaults to full-screen while preserving the multitasking option of two apps side-by-side. Another nice consequence of turning the Tablet mode on is that the touch keyboard is automatically triggered every time any text field gets focus, no matter the type of application. This undoes the need to launch the touch keyboard manually and lets the operating system take the wheel and ensure everything is handled corretly. The only disadvantage as opposed to the modern applications is the fact, that keyboard doesn’t shift nor resize the app window and overlays it (even in case it is pinned to the bottom of the screen). This means, that some content may become invisible (for example tooltips or context menus).

Outside of Tablet mode

But what about the case when you, for some reason don’t want the Tablet mode on but still want to enjoy the automatic handling of text input by the operating system? A inconspicuous setting can make just this happen!

Open the Settings app, go to Devices category and select Typing – here scroll down and you will see a setting that is by default turned off (for some reason, I can’t really understand why) – to show the touch keyboard in case of input while no keyboard is attached. This is the perfect solution for most cases and makes using all apps with touch a very pleasant and consistent experience.


Updated – .NET Framework 4.6.2

In August 2016 Microsoft announced a new update of .NET Framework 4.6.2. In addition to a very useful addition of Per-Monitor DPI for WPF, this update also addressed the problem with touch keyboard.

WPF apps targeting the new version of the framework support automatic invocation and dismissal of the touch keyboard, matching the behavior of UWP apps on Windows 10. That means you don’t have to make any additional changes to your new apps to support the touch keyboard.