Ask Reuben

Focus Stealing

Why when I start a program from a [Terminal session / Genero Studio / Our Menu application ]  does the [ Genero Desktop Client / Browser ] not get the focus and instead flash in the taskbar?

Older PC users may remember back to a distant time when they could be typing away in Word / Excel etc and all of a sudden a modal dialog would appear that read something like “You have new mail, do you want to read it now?”  The keystrokes they were typing would suddenly be diverted away from the application they were in, and instead be captured by that dialog.  If the modal dialog had a Yes/No button then it might be answered unintentionally by the user typing Y, N or Enter etc.  This concept of an application grabbing the focus from the current application is known as Focus Stealing.

A typical scenario is that you could be working in Application A and that application has the window in the foreground and the keyboard focus.    Application B then brings one of its windows to the foreground and grabs or steals the keyboard focus.  This is illustrated with something like Word as Application A, and Outlook as Application B as mentioned above with the Outlook dialog stealing the focus.  In the table below I have added a few additional applications that might play the role of Application A and Application B

  • Application A
  • Word
  • Terminal Emulator (e.g. Putty)
  • Genero Studio (generostudio.exe)
  • 3rd party Menu Application
  • Application B
  • Outlook
  • Genero Desktop Client (gdc.exe)
  • Browser
  • 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.