SetForegroundWindow not reliable on Win 7

[Baker]

Windows 7 security prevents Windows from making themselves the active app except under specific circumstance. This isn't a workaround for this and if there is, it shouldn't be used.

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

The annoying behavior this can cause is if you switch to another Window while an engine is loading, the engine assumes that SetForegroundWindow will give it focus and do things with the mouse movement clipping and so forth.

The solution would be for engines to not assume they have the focus during mouse and video initialization and check to see if is Foreground window ( http://msdn.microsoft.com/en-us/library ... 85%29.aspx ). Maybe. There might be a better way looking at system messages and stuff.

This isn't that much of an annoyance, but upon discovery it is a bit perturbing.

[Spike]

you should still get a WM_FOCUS or whatever it is message whether you're programmatically forcing focus or not.
the pain is with fullscreen apps.

fte suffers from this a lot. I'm hoping that a large part of that is 'just' because I'm usually running it in a debugger with lots of dlls being checked for debug info every single time its started...
But yeah, attempting to steal mouse input when you don't even have focus is a nasty side effect.

[mh]

[Baker]

The only "pain" I suffer from this problem now is on video mode switch (single pass video startup largely eliminated the issue).

I've been thinking and I have what might be a solution:

1. On video mode change, release everything but do not do DestroyWindow.
2. Instead of doing CreateWindowEx, just resize the existing one.

Haven't tried this yet. But in theory, since the same window is continuously active there shouldn't be a loss of "focus" from the perspective of Windows 7.

What I think happens is after DestroyWindow, the operating system tries to "think" about what to do. Then the new create window doesn't receive "focus" and isn't the receiver of input events. If I skip the DestroyWindow/CreateWindowEx the aggravation might go away (having some other window in front of the Quake window).

/May try to decompose those styles to see what all the settings are if those work well.

[Spike]

logically there's no need to destroy the window on mode changes.

on xp, you might find you have dodgy stuff going on when you resize the window without recreating the context, but vista no longer corrupts the video/texture memory randomly, so anything vista onwards should be fine with just resizing the window. No loss of focus, no loss of textures that then need reuploading etc.
the issue there, however, is that there are many reasons to do a vid_restart other than just a video mode change, and many of them are most easily implemented by letting the driver blow everything away for you, so recreating the gl context is still useful.
maybe add a vid_resize command that skips context destruction.

but you're correct. even if you do destroy the context, you don't have to destroy the window too (including on xp), and thus shouldn't loose focus.
You can still fail to gain focus at window creation time, however.

[Baker]

[mh]

I'm just so happy that D3D handles all of this automatically for me.

And with 11 there's no more D3DERR_DEVICELOST either.

[Baker]