Hello,

I've run into an issue involving windows focusing and Input, but the problem is more related to windows focus. Basically, I've programmed the mouse cursor to freeze onto the center of the screen when the game starts, to allow the user to rotate the camera. The user can then switch back and forth between camera mode and cursor mode by right clicking. However, the game relies on the WM_ACTIVATEAPP message to forcibly switch back to cursor mode so the mouse doesn't get locked up while the game is unfocused. The game also goes into a low-processor mode at this time. This is all fine, and seems to work most of the time.

The problem I'm encountering only seems to happen when the game starts unfocused. I know this is a rare situation, but I'm hoping there is a solution, nonetheless. When the program's window is created while another window is on top of it, it starts up without ever receiving a WM_ACTIVATEAPP message, so I'm not sure how to detect the situation.

Is there any other way to detect your app starting in the background? Or maybe a better way to handle the whole focus/unfocus situation? Or should I just ignore this problem, knowing that very few players will ever start the game and immedately jump to another window?

Thanks much for any advice

Yes, that will help significantly. Thank you. I think I'll create a CheckFocus() function that can be called anytime something (such as input polling or graphics locks) doesn't succeed, then this function can check the focus state using GetFocus() and manually trigger an unfocus when another window is above it. My input system was already spamming its text log with "GetDeviceData() failed" messages, so this sort of fixes both problems. Thanks again.

Ok, really strange thing to report. GetFocus() appears to be returning my window's handle, even when it starts in the background. The titlebar to my application is color-coded as per unfocused windows, yet the function continues to return my app's window handle. Does this make any sense?

Microsoft's description of GetFocus() is that it shows the focus for the keyboard. Is it possible that my application has the keyboard focus even though its being covered up by several other windows with mouse focus? edit: I can type into text boxes while its happening, so it seems unlikely.

Note that once I focus my game and then click on another window, everything responds correctly as it should. Its just the starting up unfocused part that is really throwing me off. Has anyone else run into this issue?

Its pretty tricky to actually test this (start an app and then bring another one into the foreground before the first app's window is created). I've actually been relying on Visual Studio's "Start Debugging" command to slow it down for me. Is it possible that Visual Studio is interfering with the focus states? edit: nope, I just tried using Sleep() before my window is created, and it has the same effect.

You cannot rely on the titlebar color to tell you that your window has focus. The titlebar only tells you that a window is active. A window can be focused without necessarily being active. Also, the active window is usually indicated by the titlebar color, but some floating-toolbar implementations (like those in MFC) usually override this as well (by suppressing the WM_NCACTIVATE message or changing some flags in it, IIRC). The only way to tell if your window has focus is via the WM_SETFOCUS message (or with the GetFocus API).

Also, the mouse doesn't have much to do with all this. It might be that the window needs to be focused first, before it can acquire the mouse capture (SetCapture, assuming you're using this), but I'm not 100% sure about this - I haven't tested it in recent Windows versions. In windows XP, I think any window could have the mouse captured. Even so, any other window is free to take away the mouse capture at any time. I think you can stop that from happening by not calling DefWindowProc for WM_CANCELMODE - "the system sends this message to the active window when a dialog box or message box is displayed".

And by google-ing all these window messages, I found this article, which seems to do a better job at explaining things than I did: http://www.drdobbs.com/avoiding-trouble-with-mouse-capture/184416474