Yeah, AllowSetForegroundWindow (note I refered to that, not SetForegroundWindow
) works pretty well, but as I said it's not perfect, even when things don't intentionally steal the focus. There are cases where things seem to take the focus just by opening a window normally.
In particular, the case with different parts of multi-threaded apps "taking" focus from themselves is particularly hard to fix/avoid (for both Windows and app developers).
I think there are other cases, too, but it's hard to be sure as it's hard to reproduce and I think depends on "phase of the moon" type bad luck to trigger.
(e.g. There's weird stuff like, if I remember correctly, what happens if you have a window with the focus, disable its parent, then destroy the window itself... or something like that... The details aren't important but you can do something that causes your app to lose the focus and the window manager is forced to reassign it to some other window/process. That means a bug in one program could cause another program to get the focus out-of-the-blue and appear to steal focus when it's really innocent...)
As for The API That Shan't Be Named, there are so many ways for something that really wants to to steal the focus that having an explicit API for it doesn't seem that bad. You can't stop it happening so might as well provide an API that does it in the least-bad way (and in a way that you can hook in order to see which programs call the API). I mean, better some app calls that API than does something like injecting code/keystrokes/mouse-events into the foreground process to make it call AllowSetForegroundWindow... If some app keeps taking the focus I'll just stop using it, but if instead weird things happen involving various apps then I might not know what's to blame.