Automatically pop up tablet touch keyboard on WinForms input focus

Issue

When I run a WinForms (or Delphi, see at the end) application on Windows 10 in a tablet mode, a touch keyboard does not pop up automatically, when an input box is focused.

I believe that this should happen automatically, without any additional code/setup.


For a test, I have the simplest VS 2015 WinForms desktop application with a single TextBox control.

enter image description here

It’s simply the default Windows Forms Application C# project as created by Visual Studio. No code added, no properties changed. Just the TextBox was added, by dropping from the Toolbox (again no properties changed):

this.textBox1 = new System.Windows.Forms.TextBox();
this.textBox1.Location = new System.Drawing.Point(64, 27);
this.textBox1.Name = "textBox1";
this.textBox1.Size = new System.Drawing.Size(100, 20);
this.textBox1.TabIndex = 0;

To verify my assumption that the pop up should be automatic:

  • I’ve tried to run Windows XP version of notepad.exe on Windows 10. It automatically pops up the touch keyboard. I doubt the Windows XP had any explicit support for touch keyboards.

  • I’ve also tried some ancient MFC applications (for example FileZilla 2.2.15 from 2005). It also pops up the touch keyboard on all its input boxes. Again, I’m pretty sure, the MFC had no explicit support for touch keyboards either.

  • The same for applications built on wxWidgets (for example FileZilla 3.x).


It looks like there’s something broken in WinForms that prevents the automatic popup. Interestingly, the automatic pop up works:

  • for (editable) combo boxes (ComboBox with DropDownStyle = DropDown)
  • for text boxes in a password mode (TextBox.PasswordChar)
  • for rich text boxes (RichTextBox)
  • when the input box has focus at the moment the hardware keyboard is "removed" (I test this by flipping the screen on Lenovo Yoga notebook), but never after.

I’ve seen all the hints about an explicit popup by running the TabTip.exe. E.g.:

Most of the "solutions" offer a code like this:

var progFiles = @"C:\Program Files\Common Files\Microsoft Shared\ink";
var keyboardPath = Path.Combine(progFiles, "TabTip.exe");
this.keyboardProc = Process.Start(keyboardPath);

But I cannot believe this could be the "official" way. If for nothing else, then because there’s no clean way to hide the keyboard opened by running the TabTip.exe (solutions include hacks like killing the process or sending Esc key).

And actually the above hack does not seem to work anymore in Windows 10 Anniversary Update:


Interestingly, I see the same behavior with Delphi/C++ Builder/VCL applications. The keyboard does not pop up for edit boxes (TEdit). It does pop up for combo boxes (TComboBox) and for edit boxes in a password mode (PasswordChar). Interestingly not for TRichEdit, what is notable difference to .NET RichTextBox, that maybe worth investigating.

This (unanswered) question describes an identical behavior:
Application written Delphi XE8 touch in edit boxes keyboard not appear in Windows 10.

Solution

As hinted by Ofek Shilon’s answer, it seems that the touch keyboard can leverage the UI automation.


One can use implementation of UI automation from UIAutomationClient.dll.

For the UI automation to be magically injected into an application, class initializer of the assembly internal class UiaCoreApi have to be triggered.

On can achieve that for example by calling seeming no-op:

AutomationElement.FromHandle(IntPtr)(-1)

Another way is to implement automation UI explicitly. For that implement the ITextProvider/IValueProvider interfaces for the respective input control.

To bind the implementation of the interfaces to the control, handle WM_GETOBJECT window message with lParam = RootObjectId.

For an example of implementation, see


Though interestingly, controls, for which touch keyboard works out-of-the-box (like combo box or password edit box, see the answer), do not implement the WM_GETOBJECT/RootObjectId. There must be a different machinery behind them.

Answered By – Martin Prikryl

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply

(*) Required, Your email will not be published