Jump to content

  • Log In with Google      Sign In   
  • Create Account

Issue when game starts unfocused (Windows)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Stephany   Members   -  Reputation: 136

Like
0Likes
Like

Posted 22 July 2014 - 03:52 PM

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



Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 15736

Like
2Likes
Like

Posted 22 July 2014 - 04:12 PM

You can use the GetFocus() function to determine if any windows owned by your program have focus. If you initialize based on this state and then handle WM_ACTIVATEAPP as you currently do, you should have your bases covered.

#3 Stephany   Members   -  Reputation: 136

Like
0Likes
Like

Posted 22 July 2014 - 05:07 PM

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.



#4 Stephany   Members   -  Reputation: 136

Like
0Likes
Like

Posted 22 July 2014 - 05:50 PM

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.


Edited by Stephany, 22 July 2014 - 05:55 PM.


#5 Buckeye   Crossbones+   -  Reputation: 4926

Like
1Likes
Like

Posted 22 July 2014 - 06:32 PM

I haven't set up a test for this, but you might try calling GetForegroundWindow() after you create your window to see if the user is still with you. You should also keep track of WM_SETFOCUS messages.


Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#6 tonemgub   Members   -  Reputation: 1139

Like
1Likes
Like

Posted 23 July 2014 - 12:55 AM

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 smile.png


Edited by tonemgub, 23 July 2014 - 01:14 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS