This is my first WPF project and I'm attempting to create an application for my engineers. They will be using a Tablet PC with Windows 8. They execute the application and inspect a machine to verify if it has some issues.
I made this application using winforms but I couldn't get the keyboard input to pop up and let me type in stuff. So I switched to WPF (since I will need to provide a signature capture as well). This is what I was looking for when tapping on the textbox (in red):
I started by creating a textbox just to see if the keyboard layout would pop up. The only way I could pop up the input panel is by using the following code:
Private Sub TextBox1_TouchDown(sender As Object, e As System.Windows.Input.TouchEventArgs) Handles TextBox1.TouchDown
Process.Start("TabTip.exe")
End Sub
There has to be an easier way ... I must be missing something completely. Is there another control I can use to make the keyboard input pop up automatically? Without having to provide code?
Maybe you should use a Custom WPF Control that mimics a keyboard like, WPF Touch Screen Keyboard because working from a managed enviroment like .Net to the nativw Windows API is a bit difficult.
Also have you tried a Windows 8 Metro application I think in there is trasparent to the programmer the use of keyboard.
Related
My WPF Windows Desktop application is with touch support - so when I tap on TextBox the keyboard pops up.
I'm trying to write a test using Windows UIAutomation for my WPF application.
I want to "tap" on TextBox using UIAutomation and check if the screen keyboard actually pops up.
How can I do it? I don't want to use WinAPI for that.
Thank you!
Seems like UIAutomation has no ability to tap/use touch.
We will use WinAPI do to that (already tested, it works). The solution can be found here:
https://github.com/GuOrg/Gu.Wpf.UiAutomation/blob/c0109f39062e254b3eae40275730f0e9f7efce6e/Gu.Wpf.UiAutomation/Input/Touch.cs
My goal is to show Windows 10 on-screen keyboard when user clicks on text box.
Windows 10 has option to show its on-screen keyboard automatically, even outside of Tablet mode, if specific option is enabled in settings.
However, it seems this logic has some serious issues when working with WPF applications - flickering, not showing up at all etc. You can easily test it on simple WPF application with several text boxes, if you have touch screen Win10 device.
So, I've decided to control keyboard myself, which now works perfectly, with automatic keyboard display option disabled. However, I can't ensure that every users Windows 10 will have this option disabled, so I'd like to make Windows "ignore" clicks on text boxes in my WPF application, so only application itself controls keyboard visibility.
So, my question is - is there any way to make Windows ignore focus on particular text boxes?
PS. If there is no clear way to do this, I would be grateful for any hints towards how Windows actually gets information about WPF text box being edited, so I can maybe play around with my own TextBox implementations, which will not trigger this logic.
Update:
It seems, it is possible to remove "hooks" keyboard is using to find out that text box is focused, by using FrameworkElementAutomationPeer instead of TextBoxAutomationPeer in custom implementation of TextBox, yet this ruins possibility to use this text box in automation (which I don't like).
I don't have a touch screen device to test on - but from my quick mouse clicking tests I seen there is a TextBox.Focusable = false;
https://msdn.microsoft.com/en-us/library/system.windows.uielement.focusable(v=vs.110).aspx
This how ever makes it unable to get keyboard input, so maybe put another method on a TextBox like:
txtBoxTestFocus_MouseDown or txtBoxTestFocus_TouchDown which then could set txtBoxTestFocus.Focusable = true;
Not sure is this will help, as I've been unable to test it sorry
I'm developing a WPF application for tablet.
Since the framework 4.6.2, the virtual keyboard appears when a control gains focus.
I have a TextBox :
When this one gains focus so it becomes hidden :
Exists it native solution for correct this ?
Or must I manage a scroll viewer ?
Or show a dialog with my TextBox ?
I had the same issue with an application of my own, I ended using WPFTabTip which is open source and works like a charm. It is available through nugget also.
By using it you will need only one line of code:
TabTipAutomation.BindTo<TextBox>();
It automatically handles the visibility issue by moving the focused UIElement into view.
If you do not want to use the project you can see the source code and take what you need also.
I need a multilingual Keyboard for my Silverlight WebApplication. I have now written it with Windows.Forms and Sendkeys. It works fine.
Now the problem is that I want to call it inside from the Silverlight WebApplication with a Click Function on a Textbox or a button so when its pressed the Keyboard pops up. I thought about running the Windows.Forms Application in the Background and tried to FindWindow() with Silverlight but it did not work at all.
I am not sure about using winform. But, you can use win32 methods (so, I guess Winforms too) in Silverlight 5 using PInvoke
We have a scenario where we are exposing a set of WinForms UserControls via COM to a Legacy VB6 application. We have 3 different controls which have a MenuStrip on it that has the Control + F shortcut key mapped to a menu item which invokes a control specific find items dialog when the shortcut is entered. When we try testing this code in our WinForms shell the appropriate dialog (the one hosted in the active MdiChild) pops up when all 3 controls exist, but in the VB6 host the wrong dialog usually appears (it seems to always be the dialog for the first control which was created).
I'm fairly certain this has something to do with message pumps and all, but I can't seem to figure out how to ensure that the proper ToolStripMenuItem is getting invoked when we enter the shortcut key.
I know the option of using a global/singleton ShortcutKey manager/service that overrides ProcessCmdKey is a possibility, but that would be the last resort we want to fall back on. I just get a feeling that a message pump needs to be started.
This may be inappropriate to your needs. And it might only apply to VB6 specifically. But have you considered having VB6 use the standard menus, and just have it hold onto the keyboard shortcuts, and trigger things appropriately? You could then simply hide the individual menus (but they should still fire their events).