What do you do if your DirectX* desktop game requires keyboard input, but is running on a Windows* 8 platform without a physical keyboard? If your game runs in a window, the user can manually invoke the touch keyboard from the taskbar but that can be unintuitive, and doesn't help at all for full-screen games. You could write a custom keyboard overlay within your game. That approach can be harder than it seems at first blush, with lots of corner cases to verify with language support, modifier keys, and event handlers to write and debug.
Things would be much simpler if you could access the built-in keyboards provided with the OS. Unfortunately there is no Win32 API call to invoke the keyboard, so this approach is also not as simple as it could be. It is possible though, and by leveraging your existing keyboard handling it can save quite a bit of development time. This sample illustrates one method of invoking the built-in on-screen keyboards, and points out some of the modifications needed to do so seamlessly.
The Windows* touch keyboard has a fixed location in the lower half of the display. Hint: if your application uses keys that are not part of the default reduced key-set, enable the full keyboard layout via Settings -> Change PC Settings -> General -> Make the standard keyboard layout available.
The alternate keyboard is not quite as seamless, but has the advantage that it's location and size can be controlled programmitcally via registry settings. If your game's input field(s) are positioned where the touch keyboard would obscure them, you'll want to use this keyboard instead.
Many desktop games will be written using full-screen exclusive mode. This presents a problem when using the built-in keyboards, because either the invoked keyboard will be hidden, or raising the keyboard will force the game out of full-screen mode. Transitions in/out of full-screen exclusive mode come with a raft of resource re-acquisition or re-sizing considerations, and are generally a pain point that you don't want to add to your keyboard input handling. The solution demonstrated in this sample is to run the game in a maximized borderless window, rather than full-screen exclusive mode. I listed some of the details related to implementing borderless windowed mode in a previous blog post. The advantage of using a borderless full-screen window is that raising the keyboard window does not disturb then game other than temporarily pushing it one level down the z-stack. The game continues to run in the background to process keyboard input, and it regains focus automatically as soon as the keyboard is dismissed.
We can hope for more explicit control of the Windows* keyboards in future APIs, but for the moment the workarounds demonstrated in this sample are one way to achieve on-screen keyboard input today.