- Application A
- Terminal Emulator (e.g. Putty)
- Genero Studio (generostudio.exe)
- 3rd party Menu Application
- Application B
- Genero Desktop Client (gdc.exe)
- 3rd party Menu Application
Over the years operating systems have evolved different strategies to try and prevent focus stealing.
In Windows XP I think it was, you might recall seeing an entry in the taskbar flashing. You would be attempting to start a Genero application, and instead of the GDC or Browser window becoming the foreground window, instead you saw the GDC or Browser entry in the taskbar flash whilst the program you were in retained the focus. You had to click in the task bar or on a GDC or Browser background window in order for it to get the focus.
This behaviour was controlled by two registry values. One of these was named “ForegroundLockTimeout” and it said that Application B could not steal the focus unless Application A had been idle for X milliseconds. The default value of 200,000 meant that Application B could not steal the focus from Application A unless Application A had been idle for 200,000 milliseconds or 200 seconds.
The second registry value was named “ForegroundFlashCount” and it said that if Application B attempted to steal the focus from Application A, its entry in the Windows Taskbar would flash X times and its default was 3.
It should be noted that these applied if Application B attempted to steal the focus from Application A. If Application A started Application B then Application B could take the focus as the O/S knew it had been started by an action in Application A. This made sense because if you were in Windows Explorer, double-clicking on a file to start the application, the focus should go to that application.
The current situation I believe in Windows is a little less strict although I could not find a definitive set of rules. These two Window API calls https://docs.microsoft.com/en-gb/windows/win32/api/winuser/nf-winuser-setforegroundwindow and https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-allowsetforegroundwindow both have the following or similar in the remarks section …
The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
- The process is the foreground process.
- The process was started by the foreground process.
- The process received the last input event.
- There is no foreground process.
- The process is being debugged.
- The foreground is not locked (see LockSetForegroundWindow).
- The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
- No menus are active.
An application cannot force a window to the foreground while the user is working with another window. Instead, Windows flashes the taskbar button of the window to notify the user.
If you read that and substitute Putty / Genero Studio / 3rd party Menu application as the “foreground process” and GDC / Browser as “process” then you can see the sort of logic that is being applied at the operating system level to determine if one application can steal the windows focus.
There is little we can do within the confines of the operating system and each operating system is different. On Windows changing the ForegroundLockTimeout registry setting is an option but this applies universally, you can’t turn it on/off for individual applications and say only allow gdc.exe to steal the focus. Other things to note is the clause “the process was started by the foreground process”, so allowing Genero Studio to start the gdc.exe rather than starting it via command line or desktop shortcut might help.
I hope that has given you some insight into the concept of focus stealing and can recognise when it is occurring and why Operating Systems try to prevent it occurring.