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]

I'd noticed this recently under D3D11 and had assumed that it was due to stricter handling of window styles. Seems like MS are clamping down on people partying with window styles/etc in a more general manner (we can blame cowboy programmers who abuse the API for this).

The following are the window styles that DXGI automatically sets for a windowed mode:

Code: Select all

	DWORD WindowStyle = 348127232; // this is the same style as is enforced by DXGI for a windowed mode
	DWORD ExWindowStyle = 256; // this is the same style as is enforced by DXGI for a windowed mode

I haven't bothered decomposing these into style bits, and I also haven't bothered (yet) finding the styles it sets for a fullscreen mode (there's no need with D3D), but my observation is that if you set these styles, respond to WM_ACTIVATE properly, and don't try anything fancy (like SetForegroundWindow or "fullscreen windowed" modes) then everything works in an expected and predictable manner.

[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]

on xp, you might find you have dodgy stuff going on when you resize the window without recreating the context

I wasn't suggesting not recreating the context. Release everything, but keep the window. Resize the window and restyle if needed. Recreate everything else like normal.

[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]

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

Getting rid of DestroyWindow and reusing the window and using some of MH's hints on how to get the actually "workarea" of Windows works great. I had to kill ... of all things ... a HWND_TOP somewhere to get the result I wanted (strange ...) I guess Windows doesn't really honor that any longer and reacts strangely to it.

No windows come in front of Quake ever, Quake never loses focus bizarrely to some other window.