none
Automationpeer? On-Screen-Keyboard RRS feed

  • Question

  • Hi,

    I want to enable my .Net 4.0 WPF-application to "interact" with the on-screen-keyboard. Actually all I want is the normal usage: popup when focus is on textboxes.

    All sources I find tell me, to use AutomationPeer and not use selfmade stuff, but I do not find any good tutorial or sample app.

    Also these sources say, within the .Net-provided textboxes AutomationPeer is already defined and I don't need to worry about it. But on my computer (dell optiplex <- touchscreen with win8) the osk just ignores my app.

    So finally I landed here to ask for help and tipps for the right direction.

    PS: In earlier versions of windows one could enable tablet-functions. A neat text input panel could be opened for each textbox. Small and functional and not hiding the textbox behind it. Why is it not available on win8 anymore?

    Please Help. Any tipp appreciated.


    JEns D.


    • Edited by Jens D. _ Monday, March 18, 2013 10:49 AM
    Monday, March 18, 2013 9:59 AM

Answers

All replies

  • Hi, 

    From here:http://stackoverflow.com/questions/11874029/how-to-bring-up-the-windows-8-on-screen-keyboard-in-a-desktop-app

    Executing osk.exe will pop up the more old-fashioned on-screen keyboard. The Windows 8 touch keyboard will pop up by executing

    C:\Program Files\Common Files\Microsoft Shared\ink\TabTip.exe


    Cheers, Amy

    Tuesday, March 19, 2013 1:59 AM
  • Hi Amy,

    thanks for your answer, but that is not quite what I meant. Of course one can start the keyboard via shell, but it should work automatically when no real keyboard is present. Windows has built in automation for that. But what is missing is a good how-to or best practice for wpf applications to support that automatic and that is where my question is heading.

    Maybe its a configuration thing on my Touchcomputer, but then again there is no "Tablet"-Option on windows preferences like there was on my old vista tablet.

    So... grateful for further ideas...


    JEns D.

    Tuesday, March 19, 2013 8:15 AM
  • I think the on screen keyboard is a risky way to go.

    Personally, I would instead take a look at the various codeproject controls like:

    http://wpfkb.codeplex.com/

    http://www.codeproject.com/Articles/145579/A-Software-Virtual-Keyboard-for-Your-WPF-Apps

    Good luck.

    Tuesday, March 19, 2013 4:25 PM
    Moderator
  • Ok, thank you.

    But why do you think, the ms keyboard is a risky way? I figured, that (if working) the ms keyboard would take away from me the descision on how or when to display the keyboard. Also I liked the idea of an option for the handwriting recognition (which is imho a faster way to enter text).

    If you say to use codeproject code, do you know also of a recognition feature for handwriting?

    I'm completely surprised, that there seems to be no best practice for that...

    Thanks again...


    JEns D.

    Wednesday, March 20, 2013 8:10 AM
  • I don't think there's much use of handwriting with WPF apps.

    There are several threads I've seen from people saying OSK has caused them problems with WPF.

    You're starting another process which wants to sit on top of stuff and will use a different way of displaying stuff than WPF.

    Plus, once you start a separate process then you're asking for issues stopping the thing.

    BUT

    Essentially OSK just inputs to whatever has focus.

    I suppose the user can choose to start it up and shut it down,

    Wednesday, March 20, 2013 9:57 AM
    Moderator
  • Hi Jens.D

    I provisionally marked Andy's reply as answer.

    Please  feel  free to unmark it if you think the information does not help.

    Regards,


    Lisa Zhu [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, March 27, 2013 12:33 PM
    Moderator
  • Well,

    I suppose. But I am VERY unhappy with the result. I don't think that this is the way to go. If MS promotes "touch" and "touch-first" for their OS, there need to be better solutions for this kind of problem.

    For now we are going to waste the space on the screen for a fixed soft-keyboard. Our customers much like ourselves will not like this solution, but afaik thats the best we can do for now.

    I think without starting the overall win8 discussion - this is a huge drawback. And even a step back from Vista, which had a better tool/interface for simple text-input with a pen on tablet devices. It was small fast and practicable. With win8 it is again just a waste of screen-space.

    MS should definately invest more time into this topic!

    Thanks for your help, Andy


    JEns D.

    Tuesday, April 2, 2013 8:41 AM
  • For what it's worth.

    I think the assumption is that the OSK is part of the operating system rather than an application.

    The standard approach with OS stuff is to allow the user to control them.

    If you took that line then the problems starting and then stopping it go away, since it's not part of your app.

    I also get the impression the problems are less on Win 8.

    There again I've yet to see a business using win 8 and finding issues is pretty unlikely if you don't use it.

    Tuesday, April 2, 2013 10:36 AM
    Moderator
  • You can show the Windows 8 touch keyboard using the Window Store API's from within the WPF application:

    http://brianlagunas.com/showing-windows-8-touch-keyboard-wpf/

    Hope this helps

    Wednesday, December 18, 2013 3:38 AM