SOLVED: Bringing up a specific window

[Equillian]

So I have a way to bring a windows, say "outlook" to the foreground, but it's completely unreliable by using:

Code: [Select]

Display windows '*outlook*' as [Maximize]
Play random sound (from directory: c:\sounds)


This works, until it doesn't. The sound plays EVERY time. All I have to do to get it to work again is to switch Maximize to Restore (or anything else really).

What is the proper way of bringing a specific window to the foreground?

[Equillian]

I thought I might add that I have roughly 10 of these, they all behave the same way.

[Pfeil]

Try the "Show" option.

Note that windows that are "minimized" to the system tray cannot be brought back up using this action, as the window will not be available (this is a Windows restriction and not specific to VoiceAttack).


Switching window focus programmatically can be unreliable, as Windows attempts to prevent focus stealing (I.E. background windows forcing themselves to the foreground to become the active window); Again, this is not specific to VoiceAttack.

[Equillian]

Worked for a second (like the other options), then stopped. Outlook's icon begins flashing in the taskbar like it tried 'something'. MS Teams, and Outlook are sitting on my 3rd monitor, both maximized. I say "show teams", it works, "show outlook", it works, "show teams", it works. Give it a couple minutes, "show outlook"; outlook flashes, but doesn't come to the foreground.

[Gary]

I'm having the same difficulty with the Outlook application.  It just blinks in the task bar and does nothing else.  If I have Outlook open in Chrome (using the window title *outlook*), that works as expected.  Not sure what's up with Outlook.

[Equillian]

Wow you guys are RESPONSIVE!!! I really appreciate it.

So regarding outlook, my issue can be Outlook, Evernote, MS Teams, Discord, Google Chat. Once it stops working, it stops for all of them.

[Pfeil]

If you close Outlook, does the issue still occur once switching windows is working again?


As mentioned, switching focus to another window programmatically can be problematic; VoiceAttack is instructing Windows to bring up a window, however Windows doesn't necessarily do so.

The blinking in the taskbar you're seeing can be part of the aforementioned protection against focus stealing, showing that an application wants to be brought to the foreground, but Windows is refusing to let it.


On my machine, focus switching like this refused to work for a period of several months, even though it did before, and started working again at some point without any manual configuration changes. It may be related to certain Windows updates, though I can't verify that correlation.

[Equillian]

Yeah closing / reopening makes no difference. Alright, well I just wanted to know if I was doing it wrong. I didn't mean for you to take up the fight with Microsoft

Thanks for the fast replies and willingness to help!

[Equillian]

I may have figured it out. I'm testing now, but I don't want to post attempts that don't work.

[Equillian]

Ok I think I got it:

HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout

I changed this value from 30d40 to 0 (that's a zero). I can't tell anyone who comes across this that they won't be frustrated by another program that likes to steal focus, but this seems to have resolved it.

I couldn't have done it without you two. Thanks!

For anyone in the future:
1. Windows+R to open the run dialog box.
2. Type Regedit
3. Navigate to HKEY_CURRENT_USER\Control Panel\Desktop\
4. Find ForegroundLockTimeout in the list on the right
5. Change the value (by double clicking) from 30d40 to 0
6. Restart your computer.

To revert the changes, follow the same instructions but just change 0 to 30d40

[Pfeil]

Interesting workaround; Apparently at some point (back with Vista) Microsoft themselves described it, but the underlying issue was since fixed with an update.

Do keep in mind that you changed that value, should you ever experience issues with focus stealing.


I will note that on my machine the value is different (quite a bit higher, in fact), even though it does not currently have issues with focus switching.

Looking into it, the documentation on the API method used shows that setting that value to 0 overrides all other checks, effectively disabling any protection against focus stealing (including when you're interacting with an application, E.G. navigating through context menus or typing).

[Equillian]

Do keep in mind that you changed that value, should you ever experience issues with focus stealing.

Yep! It's already added to my documentation 

If I can help one person in the future, it was worth it.