Closed Bug 1200799 Opened 9 years ago Closed 9 years ago

Use InputPane.TryShow and InputPane.TryHide instead of invoking TabTip.exe directly

Categories

(Core :: Widget: Win32, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jaws, Unassigned)

References

Details

From an email thread about a way to reduce the need to specifically look for TabTip.exe and ShellExecute it,

> Are you able to use the InputPane APIs that we’ve converged for Windows 10?
> Instead of having to invoke Tabtip directly, you should be able to call
> InputPane.TryShow() and InputPane.TryHide() now to manipulate the touch
> keyboard.

> https://msdn.microsoft.com/en-us/library/windows.ui.viewmanagement.inputpane.tryshow.aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-1

> In these cases we will use the OS heuristics used everywhere to prevent the
> actual showing and hiding in cases where there is no touch screen or there
> is a physical keyboard connected etc. If focus is moved to a non-editable
> field (that is, no TextPattern provider) though, the keyboard will still
> dismiss automatically. It’s not perfect but hopefully it will work better
> than invoking tabtip.exe directly.
Based on my experiments with the Titlebar code ( https://reviewboard.mozilla.org/r/12599/diff/1/ ) I am not sure if the InputPane's GetForCurrentView would work from a non-winrt app.

I also don't know that we expose the TextPattern provider correctly right now.
I've gotten confirmation from someone at with Microsoft that these APIs are not available for non-WinRT apps and there are no immediate plans of adding them. They may come in a future release though.

For now we will have to improve the robustness of our current approach. I've filed bug 1209198 as the next step.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.