LabVIEW
Windows UIAutomation mit LabVIEW Applikationen
Solved!
I'd split the problem up into two problems. I did minor proof-of-principle testing, it might help to get you started.
1) detect when the touch keyboard should appear.
2) show the touch keyboard.
3) hide the touch keyboard.
1) seems fairly easy with an event structure or callback event. Not sure if it is that easy. For instance, clicking the control doesn't mean it actually got key focus. So I think it should be a combination of catching key down event, and checking if the control has key focus.
2) Starting "C:\Program Files\Common Files\Microsoft Shared\Ink\TabTip.exe" works for me. I've read online that it doesn't work for a lot of people, that they actually have to simulate a mouse down on the TapTip window. You have to start it with a .NET process.start method. Starting with the command line doesn't work, as LabVIEW looses focus. You'll find Process in the System assembly, under System.Diagnostics.
3) So on some event (enter key, or something else getting focus), you'd have to kill the process. Not in the attachment.
Search LabVIEW like a graph!
@zuegerj wrote:
Unfortunately LabVIEW didn't made their controls an EditControlType.
And that makes sense, as LabVIEW has to look the same on Windows, Linux and MacOS. Not sure how that works for Windows controls...
@zuegerj wrote:
They made all controls a WindowControlType. Therefore Windows UIAutomation does not open the keyboard - it does not know if it is a control or an indicator.
Maybe Windows controls become WindowControlType, I haven't checked recently. Most LabVIEW controls have nothing to do with anything in Windows. The controls are simply graphics drawn on a Mesa3D\OpenGL canvas.
@zuegerj wrote:
I found some solutions with tabtip.exe before.
In newer versions of Windows 10 tabtip.exe does no longer open the keyboard. It just starts the service for it.
Then I wander why it works on my newer version of Windows. Pretty sure I'm up to date.
There are several tricks online to make it show anyway, by sending windows messages to the process.
Maybe MS fixed it? So it works again for newer versions?
What I think is happening is that some people try to invoke the keyboard while Windows is not configured to show it. That's not the situation: Windows is configured to use the keyboard, but LabVIEW doesn't signal Windows to show it. It could be related to the Windows version, but I wouldn't be surprised if it always just worked with the right Windows settings.
@zuegerj wrote:
Your're right. It works on my other computer. May be Microsoft fixed it. tabtip.exe might work.
However, there's no specification how to use tabtip.exe. So it's kind of unsecure if it will work on different Windows 10 platforms or not. That's why it can't be used in production in my case.
Ok. I'm not sure if there are other solutions. BTW, MS MFC applications seem to have the same issue. Really puzzling how MS ignores this...
The lack of documentation is indeed a problem. One thing that is not clear to me is how to get a numeric keyboard...
A totally different solution, maybe completely unrealistic and untested, is to use .NET FP controls instead of the LabVIEW controls. The .NET controls could be wrapped in a class, so you insert the ref in the init of the class\object and let the class handle things. But this will be a complete rewrite, and that could be a lot of work depending on the application and level of abstraction in it.
