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
Related
I'm working on a WPF application, mostly targeted at windows 10 but it could also be run on older versions. By default, if I open the app while in tablet mode, the keyboard will open when I focus a textbox, and close when the textbox loses focus, but if I manually close the keyboard it won't open anymore (very annoying as this is a natural thing to do). I can live with that, but the problem is that the keyboard opens over my application, so the user can't see 50% of it, including most of the text boxes, which makes it hard for them to select something else to 'defocus' and close the keyboard.
If I could get some notification when they touch keyboard opens, it'd be fairly easy to have some UI code to make sure the proper things are displayed, but I can't find any way to get an event when the keyboard opens.
You can use this on Windows 10 Anniversary Edition and above to get notifications from the touch keyboard.
I have a problem that appears to be new to Windows 10.
I want to create a form that is visible to the user, but with no task bar icon and that does not appear in Alt+Tab.
This is perfectly doable if one is happy to sacrifice the normal styling of a window by following the accepted solutions here for either WPF or Windows Forms.
The general advice for both WPF and Windows Forms is:
Set ShowInTaskbar to false
Enable the ToolWindow styling (either through setting the border style in WinForms or the WindowStyle in WPF)
However, this has a new, practical problem in Windows 10 when using Virtual Desktops: the moment you do the above, the WPF or WinForms window will appear in every virtual desktop. See my example application with a red background:
This affects both the Task View switching screen and the actual desktop itself. No matter where you go, the form is there!
Is there any way to show a form - or even just a bitmap - on Windows without anything appearing in the taskbar, without anything appearing in Alt+Tab and without duplicating the window on every virtual desktop?
I have spent two days researching every possible option, trying every example online, reading MSDN documentation on window styles etc. but all resort to the same method, either through P/Invoke calls or directly, but either way the result is the same.
I have a legacy application that uses Win32 (not MFC) to create graphical screens. One of the control types we use is a combo box with the droplist style (using the new Common Controls module). We have discovered a very strange thing about this control lately.
If I start the application with a mouse click, the focus indicator on the droplist does not show! This can be done using the Start->Run dialog (click OK after filling in the program to run). This can be done using a desktop shortcut (double-click). This can be done by clicking the Go button in Visual Studio 2010 to debug the program. Our user discovered this by using a small Delphi app that acts similar to Start->Run (fill in an entry field of a program to execute, and press a Launch button). If you click the Launch button, the focus indicator is missing.
If I start the application with a keypress, the focus indicator shows! Again, Start->Run dialog (but press Enter to activate the OK button). Desktop shortcut (single click to highlight the icon, then press Enter to activate it). F5 from within Visual Studio. Even the Delphi app - if you tab to the Launch button, and press Space or Enter, our application starts and shows the focus indicator on the drop list.
I have tried to create a small MFC application with just a drop list, and have started that application in all the ways described above. However, this small application always shows the focus indicator of the drop list, regardless of how I start it.
I have examined the styles of both drop lists (on my small application, as well as my actual application). They are slightly different, but changing the style of my small MFC app to match my desktop app doesn't change the behavior. Nor does changing my desktop app to match the style of the small MFC app change the behavior of my desktop app.
I modified my desktop application to require the user to press Enter after the main window is displayed, but before any graphical controls are shown. This causes the focus indicator to now show!
I have found that, when debugging my desktop app, if I set a breakpoint after the main window is shown, but before any controls are drawn, and then press F5 to continue, the focus indicator now shows. But if I click the Go button instead, the focus indicator does not show.
It seems like interacting with the keyboard somehow causes the focus indicator to show.
Note that a drop list combo box looks like a push button with a small down-arrow on the right hand side. The focus indicator is a dashed line near the inside border of the button.
I have struggled with this issue for two days now, with no indication that I am getting closer to an answer. So any insight into what may be causing this will be much appreciated.
The first comment to the question provided a partial answer. Changing the Control Panel setting for keyboard accelerators also causes the focus indicator to show, regardless of how the application is started. However, I believe this is only a partial answer.
When the CP setting is off, keyboard accelerators are supposed to show once you have pressed the Alt key. My understand, based on the blog post that Jonathon Potter linked to, is that focus indicators should show up once the keyboard is used. Entering text into an entry field probably doesn't count as "using the keyboard", but I would expect tabbing between controls to count as such.
Also, if the CP setting is off, the behavior of my application is different, depending on whether I start the application with a mouse click or a key press.
In summary, I find the behavior inconsistent. Perhaps it is correct. I find it hard to say.
I am making a WPF application that is to be used on a kiosk with no hardware keyboard. Currently we are using a third party on-screen keyboard, but the Windows 8 version is a lot better and we are thinking of switching to it.
So my question is simply if it is possible to show/hide it as well as show a numeric only version using c#.
Thanks!
David
From this source:
There is no direct way to control the touch keyboard programmatically.
Requiring the user to set the focus rather than the program is a
deliberate design decision to prevent UI churn.
See Input Hosting Manager and the Touch Keyboard for more information
on how and why this works. The User-driven invocation section of that
document explains the specific behavior you are asking about.
But, once the user touches an input control, the soft keyboard will automatically be displayed (with no extra coding needed).
Finally, to address your question on a numeric-only version of a keyboard, you may propose a different keyboard layout using InputScope on a TextBox. The different input scopes are enumerated here, but one of them is "Number".
I've published a sample on how to trigger the touch keyboard in WPF applications when a user clicks into a Textbox, its here:
http://code.msdn.microsoft.com/Enabling-Windows-8-Touch-7fb4e6de
I've been working on this sample for many months and am glad to finally contribute it to our community. Please let me know if there are any questions, suggestions, problems, etc in the sample Q&A pane
Also note that while demonstrate how to "show" the keyboard, i'm not sure how to dismiss it programmatically at this point so its important to test any actual implementation to ensure its a good experience. For example some controls like Button will dismiss the keyboard when they get focus from a TextBox, but certain ones like Checkbox will not and I demonstrate that in my sample.
When I have 2 apps open and one has the focus but I want to execute a command in the other app, it requires a click to regain focus and another to execute the command. Is there some good reason why I couldn't take focus on MouseOver? I'm working with a WPF app if that is pertinent. TIA
EDIT: Oddly enough the MouseOvers work without focus.
I would not recommend doing this. This is not a standard way of working in Windows, so you will confuse your users. People are used to clicking into an application (or tabbing) to provide focus.
However, this is a configurable setting via the Accessability Tools in Windows. It can be enabled by choosing "Activate a window by hovering over it with the mouse" globally. Let your users specify this behavior if they want it.
The setting is configurable at a system-wide level. You should never ever override the user's current setting regarding this.
MS Windows Vista -- focus follows mouse (There's also a link on how to do it on XP.)
Edit: Normally, you can click a button on a form and both bring focus to the window and click it at the same time. The origins of the current setting "eating" the initial mouse click that brings focus to a window started as a fix to a bug in the Ribbon UI. The discussion is somewhere in this video: The Story of the Ribbon. Sorry I can't narrow it down more than that, but at least the video is a great insight and work watching - maybe you can send a message to Jensen Harris if you need a faster answer.
Edit 2: I just added a button to a WPF window, and I'm able to click it as long as I can see it - whether or not the window has focus.
You can take focus on MouseOver manually