When a window gains focus via a mouse click (left, right, or middle button), and the button is held, Windows seems to automatically send a mouse released event to the newly focused window after about 0.5 seconds, regardless of whether or not the button is held for longer.
A very easy way to see this bug is to focus on another window (that is not your browser...), and then middle click on this window (it will gain focus), and scroll to the left or right without letting go. It will automatically stop scrolling for you after about 0.5 seconds, as you can tell by the cursor change.
It is annoying because oftentimes I don't realize that a window has lost focus, and I make mistakes by not dragging items as far as I intended, etc. Of course I can just click once to gain focus or alt-tab and then drag, but I'd rather not.
Is there a way such that:
The mouse released event is sent immediately to the window, to stop the drag event from happening in the first place, or
Windows doesn't automatically send a window a mouse released event?
Interestingly enough, Windows Explorer circumvents this issue by never gaining focus when you click on a draggable item. It seems that the folks over at Windows certainly know about it.
Well, I posted this same question on the Microsoft forums and the representative suggested I make a new user account. For whatever reason, this solved the problem.
EDIT: It had nothing to do with the user account, and everything to do with background processes stealing my window focus. In my case, it was the Logitech Gaming Software that came with my mouse, which stole the focus for a split second to determine what new window had been clicked on, and if necessary, change the mouse button profile. Pesky mouse.
Related
When I click the application shortcut, if the program is already open, I will show the program and enable FlashWindow. (FlashWindow(true);)
After blinking once, the taskbar is highlighted.
Theoretically, clicking on the application window would unhighlight the taskbar.
But it doesn't.
There is no problem when the window is minimized.
But it doesn't work when the window is already displayed.
I tried to get all the window handles of the application based on the process id and activated them one by one, but that didn't work either.
For this step I printed the log and used GetForegroundWindow to confirm that the change did happen.
How to solve this problem?
Is there any other way to make the taskbar blink only once without keeping it highlighted?
When I click on a non-reactive area of a win32 window in the foreground (for example, a blank space on a menu bar) and drag the mouse off, background windows do not receive mouse events. Buttons don't got into hover state, the cursor doesn't change, etc. The mouse is "captured" by the foreground window, although it doesn't receive messages either unless the mouse is over it. This state persists until I release the mouse button. Why is this, and how can I get out of this state programmatically without releasing the mouse button?
Researching this issue, I thought at first it was related to the concept of mouse capture, but it appears it is not. GetCapture() returns NULL during this state, whatever it is.
Clarification Edit: This is easy to see in the simplest of applications. Create a new Win32 project in Visual Studio with the default project template, which makes an empty window. Run it, and click and hold the blank inside of the window. Drag the mouse outside the window, and note that no buttons in background windows light up or otherwise respond to mouse-over events. Even if I stick ReleaseCapture() in the WndProc so that it fires after every message, the result is the same. It really seems like this has nothing to do with mouse capture in the Get/SetCapture sense.
I need to activate a window that is possibly behind other windows, but the window should remain behind - it shouldn't be brought to front.
Is there a way to do that? I've tried SetWindowPos with various parameters, but no success so far.
Basically, I need to close a non-active window (by posting WM_SYSCOMMAND with SC_CLOSE), but that window may show a confirmation dialog before closing. If the dialog is shown, it needs to be brought to front, otherwise the window should stay behind.
I have a NSMenu coming down under a NSStatusItem. I also have a NSSpeechRecognizer. When the NSMenu is open, the speech recognizer does not function properly. It will constantly show that it's receiving sound, until I close the menu. I need it to detect sound properly even while the menu is open.
How can I make the speech recognizer detect sound even while the menu is open? Does it need to become a "first responder" and take precedence over the menu?
I tried setting [speechRecognizer setListensInForegroundOnly: NO] and it still won't work.
If you don't understand, I am more than happy to provide clarification.
Here are some similar situations, but I don't yet fully understand.
The problem is most likely that the menu is running a modal run loop as long as it is open (for the purposes of tracking the mouse, etc...) and this is blocking the NSSpeechRecognizer's ability to function normally.
You can confirm this by bringing up the menu and then pausing into the debugger. You'll likely see two run loops; the outer, normal, one and one deeper down the stack that is running the modal loop.
In general, this is kind of an odd thing to do from a user interaction perspective. The whole point of a pop-up menu is to offer the user some commands that will be done after the corresponding menu item is selected.
If you really need "click this thing and recognize voice", I'd recommend a button that, maybe, pops up a bit of UI and then interacts with the speech recognizer without using a menu?
By now everyone writing for Windows probably knows that applications cannot (officially) steal focus from foreground processes, and why. But I have just managed to steal focus, inadvertently, and don't understand how this is even possible.
I have a Delphi app that user brings up with a hotkey (or by a mouse click, or by Alt+Tab), selects a piece of text and hits Enter. My app then minimizes (hides to the tray, even), and pastes the text user just selected into the active window. Nothing new here, plenty of similar projects out there - clipboard extenders, glossaries, macro programs, etc.
What is puzzling to me is that after doing all the above and then sleeping for 1500 ms, I restore my main form and it gets the focus back! It becomes the foreground window, even though it wasn't 1500 ms ago (tested; Windows 7 32-bit.).
In fact, I don't want this at all, so before restoring my main form I record which window has foreground and I give it back to that window after it's been given to me. I'm just curious why my app gets to be in the foreground when by rules it should not. Maybe I don't understand the rules as fully as I thought I did?
If you look at the documentation for SetForegroundWindow you see a list of conditions for the call to succeed, one of them is "The process received the last input event." So if the user does not do anything after pressing enter in your app you still have the right to steal focus. I don't know if Delphi calls SetForegroundWindow for you when the window is restored but it might be something to look into.
I don't know how you restore your window but using SW_SHOWNOACTIVATE with ShowWindow might help...