I have a game based on the Quake2 engine, and there's something that's been bugging me that I haven't been able to find a solution for. If the game is starting and another window takes focus, the game still thinks it's the active app, so it keeps recentering the mouse. The game window is usually flashing in the task bar at this point. You have to alt-tab to fix it. It might sound minor, but it happens quite often when debugging and when the installer launches the game and the readme at the same time.

Currently, the game uses WM_ACTIVATE to determine if the window is active or not. I tried a bunch of other things to determine possible focus loss, such as WM_KILLFOCUS, WM_NCACTIVATE, and WM_ACTIVATEAPP, but none of them appeared to catch this case, so I logged every event. I still can't seem to find anything that would tell me the app doesn't have focus.

Here's the log:

------- Loading ref_pbgl.dll -------
ref_gl version: PB2GL 0.34
Initializing OpenGL display.
...setting mode 17: 1280 720 W
...setting windowed mode.
(window creation starts here)
24 WM_GETMINMAXINFO
81 WM_NCCREATE
83 WM_NCCALCSIZE
1 WM_CREATE
18 WM_SHOWWINDOW
46 WM_WINDOWPOSCHANGING
46 WM_WINDOWPOSCHANGING
1c WM_ACTIVATEAPP
86 WM_NCACTIVATE
7f WM_GETICON
7f
7f
6 WM_ACTIVATE <=- Windows says the app is active at this point
281 WM_IME_SETCONTEXT
7 WM_GETICON
85 WM_NCPAINT
14 WM_ERASEBKGND
47 WM_WINDOWPOSCHANGED
83 WM_NCCALCSIZE
5 WM_SIZE
3 WM_MOVE
f WM_PAINT
GL PFD: Color(32bits) Depth(24bits) Stencil(8bits)
------------------------------------
------- Sound initialization -------
... more init stuff ...
...
7f WM_GETICON
7f
7f
7f
7f
7f
c116 (not sure what this is?)
c0d7 (or this)
7f
7f
7f
86 WM_NCACTIVATE <=- I believe this is the point at which I alt-tabbed to the game
46 WM_WINDOWPOSCHANGING
85 WM_NCPAINT
14 WM_ERASEBKGND
47 WM_WINDOWPOSCHANGED
200 WM_MOUSEFIRST
f WM_PAINT
86 WM_NCACTIVATE
7f WM_GETICON
7f
7f
100 WM_KEYDOWN
102 WM_CHAR
101 WM_KEYUP
100 WM_KEYDOWN
102 WM_CHAR
^ At this point I'm in the game window typing


Any ideas? I was considering checking if the taskbar icon was flashing and telling the game it wasn't active in that case, but that sounds like a huge hack that would likely be buggy.

You can use GetForegroundWindow, which returns either the foreground window or NULL if a window is losing activation. There is also GetActiveWindow, which returns the active window if it is attached to the calling thread's message queue, or NULL.

In addition, both WM_ACTIVATE and WM_ACTIVATEAPP are sent the the window being deactivated, with different wParams. See the links for specifics.

Looks like the problem is that Windows thinks the window is active, but it's not in the foreground. I did a check on WM_ACTIVATE to see if the game's hwnd == GetForegroundWindow(). In the case I described, it did not. If I used GetActiveWindow(), however, it thought it was the active window, even though a different window was in front and had focus.

So now, if I don't tell the game it's active when it's not the foreground window, it still won't be active when I switch back to it. It never receives another WM_ACTIVATE message (unless I switch back and forth between another window again, then it's all good).

I guess I just have to poll GetForegroundWindow() every frame unless maybe I can get more accurate information from WM_WINDOWPOSCHANGED.