I have the following scenario for an application running in a non-default desktop (it's the Bitdefender Safepay browser, for clarity):
- application creates a desktop with CreateDesktop, let's name it DK
- if the application was not launched with CreateProcess in desktop DK, it restarts itself in that desktop (STARTUPINFO::lpDesktop = L"DK")
- SwitchDesktop is called to make DK current desktop
- touch keyboard is not available
- application launches, verifies if is running Windows 8 and is a touch device
- if Win8 and touch device, it attempts to start TabTip.exe (won't go into code for now) so that the touch keyboard can be utilized in DK desktop
What I do not know is why the keyboard still appears (when process creation succeeds...) in the default desktop.
According to this page, there is a /SeekDesktop parameter that can be passed to TabTip.exe.
I have tried
TabTip.exe /SeekDesktop
TabTip.exe /SeekDesktop:DK (DK being the desktop name)
but no success. With /SeekDesktop passed, TabTip.exe starts and closes immediately.
On the other hand, osk.exe can be launched successfully in the DK desktop, but it does not exhibit the automatic behavior TabTip.exe offers (does not pop when touching input fields, for example).
So the questions that I have are these:
- Does it make sense to launch in this way TabTip.exe so the application running in non-default desktop to use touch keyboard?
- If so, /SeekDesktop is the way to go?
- If /SeekDesktop is the correct way to achieve the purpose, is there any usage/documentation available?
Some interesting links on topic:
On-screen keyboard is not displayed after you switch between two desktops on a Tablet PC that is running Windows 7
The case of ShellExecute, ShellExecuteEx, CreateProcess and osk.exe
Environment:
OS: Windows version is 8.1 64-bit
Application: 32-bit (for some runtime limitation - it uses Chromium Embedded Framework which does not have yet a stable 64-bit version)