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.
Related
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 created WPF application which allows user to interact with itself using touch. Unfortunately touch is working very bad when several instances of the same application are open.
I will try to describe the behaviour that I am facing:
Open two windows and place them right next to each other.
Touch left window with your finger and do not release it.
Any attempts to interact with the second window using touch will fail.
I have some experience of developing touch applications using WinFroms. And I never had such problems before. So I performed the described above trick with two WinForms applications and they are working just like they should - first window (with finger not released) keeps the focus but second window still allows user to perform clicks on its surface.
I also tried mixed combination - when WPF window is focused, WinFroms window still is touchable. But not the other way around - when WinForms window is focused, WPF window won't respond.
Is there anything that can be done to change described behaviour of the WPF windows?
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.
My application is using ncurses and has several windows that are continuously being updated.
In that application I have one window acting as a 'message box' (e.g. dialog) showing up when the user hits 'q', asking them if they want to shutdown. This works fine until the other windows are updated. At that point the other windows will be drawn over the dialog box making it (partly) invisible.
Calling wrefresh() on the dialog's window doesn't seem to help. How do I force the window to be on the foreground?
I had been reading manual pages all day, couldn't find anything. And of course, 5 minutes after asking my question I found the solution:
redrawwin(dialog_window);
wrefresh(dialog_window);
My dialog now stays on the foreground.
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