Window hijacking attempts to steal global focus on Windows

Question

I am a Windows developer and longtime obsessed user on how to make my system as user-friendly as possible.

Yesterday I thought about something that always annoyed me on Windows and what I took for granted, and I realized that I have a better idea of ​​how it can work, and now I wonder if it is possible to configure Windows to work like that.

The thing that annoys me is when windows steal focus. For example, I can run the installer for a program. While it works, I will switch to my browser and browse, perhaps by entering text into the email in my browser. Then the installer unexpectedly ends, and its window steals focus. Now I am in the middle of writing an email, so I can press a key that turns out to be associated with a button on this installer, and then this button is activated, performing some actions that I never intended to happen!

It doubly annoys me because I use a multi-tasking program called DexPot, and when the window steals focus, it also brings itself to the desktop on which I am now, which can be very annoying, because then I have to return it to my original desktop.

How my perfect solution to this problem will work: Every time a window tries to steal focus, we intercept it and do not let it. We show something like a toaster message that says: "The Foobar installer wants to concentrate, click" Win "to switch to it." If and when you press a key combination, it switches to the window.

Question: Is there an easy way to configure Windows to make this happen? I know very little about Windows programming. I know the AHC, and if possible, it will be great.

Answer 1

No, there is no easy way to add this behavior, but Windows is trying to do this automatically.

In theory, applications should not steal the foreground while you are actively using another application. Unfortunately, there are some scenarios in which Windows cannot distinguish between legitimate user actions that should change the foreground and unwanted theft of the foreground. The window manager usually tightens the holes slightly with each new version of Windows, but also needs to make sure that applications can come to the forefront when the user wants them, even if this desire is expressed indirectly.

For example, a process started by the current foreground process may place a window in the foreground. This is necessary so that when a user launches a window from Explorer, a recently launched process can open its main window. This permission is saved only until the next user input, so if the application starts slowly and you start working with e-mail, the application may lose foreground rights before it can use them.

See the SetForegroundWindow documentation for a list of requirements for a process to set a window to the foreground.

There are also applications that specifically use these requirements to steal permission (by attaching to the front-end queue or user input synthesizer for themselves), but I suspect this is an accident in your installer script.

I'm not sure what exactly is happening, but I suspect that the problem is with the installer running as a service and accidentally steals the foreground permission when it tries to run the application on your current desktop.

It would theoretically be possible for an external process to hook on the foreground system to redefine this and show your toast for confirmation, but it would be difficult to get right and require a significant low-level code (I would probably start with CbtHook ). This would not be possible in a scripting package such as AHK (assuming you mean AutoHotKey), but for this, C / C ++ code must be embedded in every running process.