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
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'm currently developping an application with Surface SDK running two windows (not hard to reproduce at all).
Problem is : when 1st window is clicked, she has the focus. But when I want to click the 2nd window while first is still clicked, I can't get the focus and interact with this 2nd window.
I think problem is that Windows only gives the focus to one application at a time, so you can't interact with a second window until first click is released.
Do someone know if there is a solution to force windows to interact with 2 applications at the same time ?
Cheers,
Your diagnosis is correct but unfortunately there is no solution. Much of Windows is based on an assumption that only one window has focus. (Source: I lead the team that created the Surface SDK)
A tool such as PluralInput may work for you:
https://pluralinput.com/
I'm not sure that's the right way to say it, but what I want is to for my wpf main window to have it's own bar that will behave like a taskbar, and any children windows that will be open from the main one will be placed in that bar in a similar way like the taskbar works in windows - a rectangle showing the window name for example, on click it opens you the window, if you click minimize it will minimize it to the bar, and with some option, to get it out of the main window and move it to the real windows taskbar, with another option for putting it back in. The problem is I don't know if this is even possible, and I don't know the name of such an element, so if anyone can give me any tips I'll be really thankful.
I worked on an application years ago (.NET 3.0: first WPF release!) that did exactly that. We ran into a lot of issues getting it to work, but we were pretty successful in the end. One thing we didn't support was moving it to the Windows taskbar.
The best option would be to set an attached property on each Window. This would register a Window with your custom taskbar, so if you wanted to move the Window out of your custom bar, you'd set the property to false. Setting the property to true would add it to the collection of application windows, as well as register event handlers to track the state of the Window.
One of the major pain points for us was getting the Window animations correct. If you're not running in XP, this probably less of an issue, as the animations in Vista (or is it 7?) and above aren't really showing where a Window is going on minimize. In the end, we had to do a lot of low level Win32 (p/Invoke) work for this.
Take a look at AvalonDock and WPF MDI:
http://avalondock.codeplex.com/
http://wpfmdi.codeplex.com/
We've been working on an application for the last few months that's aimed at Windows 7 tablet PCs. So we've used the Surface 2 SDK for most controls and it's all touch-happy.
I have noticed recently, though, that one of our custom controls isn't working as it should. This control provides popout menus, and these are achieved through the Popup control. On a developer's laptop, this works fine and the menus vanish when you click away from them. I've noticed, though, that on our test tablet they have a tendency to stay open.
I found that there was a SurfacePopup in the first Surface SDK, but I can't find one in the Surface 2 SDK. Did they get rid of it? Is there a 'best practice' approach?
If there's no simple solution, I may have to go old-school and add a window-sized hidden SurfaceButton below the menu when it appears, that hides itself and the menu when clicked or touched.
Beyond that I've noticed that sometimes the SurfaceScrollViewer within the popups won't work. I'm guessing this is because it's not picking up touch events properly. I tried adding this extension method to the window..
this.EnableSurfaceInput();
..but I get a NullReferenceException on System.Windows.Input.Mouse.get_LeftButton() which bizarrely suggests that it can only enable surface inputs for controls when there's a mouse plugged in.
Any ideas? They'll all be welcomed with open arms!
There's no SurfacePopup in the Surface SDK 2.0, however you can use a normal WPF popup. Then you need to make sure that it receives Touch Events by using the extension method you suggested above on the popup, not the window:
((HwndSource)HwndSource.FromVisual(popup)).EnableSurfaceInput();
Edit: As I just found out, this only works when the popup is initially open. To get it to work when the popup is opened later on, you don't need to use the popup, but the parent of it's child (see this question).
For the benefit of Daniel, and anyone else who needs a solution to this, I'll try to cast my mind back two years and explain how we got this working.
As far as I can remember, the answer was to use an adorner layer instead of a popup. Basically, every WPF control has an adorner layer, which sits above the control's UI stack. By default it contains nothing, but you can add whatever you like to it.
I got this all working by writing a custom control that allows you to place that control, with content, in the XAML and then show and hide it whenever you need to. When it's shown, it moves its contents into the adorner layer of the containing window, and when it's hidden it moves the contents back into the control itself, which is hidden from the user.
Afraid I can't go into any more detail than that, but as far as I can remember this was the ultimate solution; replacing popups (which never quite worked very well) with a custom control that uses the adorner layer.
Hope that helps!
A WinForms program will inevitably send notification to user. There are two types of notifications:
Important: user needs to take action on it
Non-Important: kind of like "there is something going on, and you might want to pay attention".
It's pretty common that MessageBox is used for both of the two types. But recently I found MessageBox is kind of annoying: it steals user's focus and user has to click to dismiss it. I want to know what's the alternatives for MessageBox and their pros/cons?
To start, here is some idea:
Statusbar: not easy to display lengthy notification
taskbar notification: does people think it's evil since most internet ads popup use that approach?
floating statusbar: Chrome/IE9/Evernote use similar floating statusbar, which is hidden when there is no link address or no message.
Chrome UI: Infobar and Status Bubble
IE9: Notification bar
We implemented a mechanism similar to taskbar notification, but placed in some coordinates inside a WinForms control.
This has some advantages:
You have some context about where (location) the notification is shown and why.
It is non modal, so it not blocks the GUI.
It's easy to implement using a owned form without border.
You can place it wherever you want.
You can show a link label with a short explanation and show help, other dialos, or link some actions if the user needs further explanation. The user experience is improved.
But I recommend using notifications only for informative messages.
You must take into account some tips about the messagebox:
It's the standard way to show information to the user.
It should be user to notify an error message or a warning. The messagebox ensures that the user, at least, clicked ok. So the user is aware that something happens. Yes, maybe he didn't read the message, but at lease he saw an error or warning.
It is possible that the user ignores other reporting mechanisms.
Hope it helps.
I have been working on a C# WinForms solution using the WebBrowser control on a form.
At this time it has three modes: Prompt; Countdown Prompt; Countdown Timer and Combo(box) prompt.
Using the webbrowser control allows HTML to be used which gives you free selection of Fonts; Colors and sizes.
I'd share what I have if I only knew how to share a solution instead of a code snippet.
What I've got works and has two parts, the designer and the prompt itself.
If an admin will contact me I can provide a download link and they can review to see what they think.