Win32 SetForegroundWindow unreliable

Question

I have a rather complex series of applications which depend on the ability to switch applications in the foreground.

My problem is, every 5 or 6 times of switching the applications in the foreground, it simply fails to bring the application forward. GetLastError does not report any issues. Often times I see the correct application flash in the foreground for a moment then the previous application is visible.

I have a Manager application which I have source for, it spawns and controls about 4 applications which I do not have source for. one of the applications it spawns/controls is also a manager which spawns/controls about 5 applications.

This is a sort of kiosk design so the user wont even have a keyboard or mouse, just a touch screen.

I have tried every combination of the Win32 calls to control them I am just out of ideas.

My first attempt was:

SetWindowPos(hApp, HWND_TOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetWindowPos(hApp, HWND_NOTOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);

My second attempt was:

SetForegroundWindow(hApp);
SetActiveWindow(hApp);
SetFocus(hApp);

my third attempt: DWORD dwThreadID = GetWindowThreadProcessId(hApp, NULL); AttachThreadInput( dwThreadID, GetCurrentThreadId(), true);

SetForegroundWindow(hApp);
SetActiveWindow(hApp);
SetFocus(hApp);

AttachThreadInput( dwThreadID, GetCurrentThreadId(), false);

my forth attempt:

DWORD dwThreadID = GetWindowThreadProcessId(hApp, NULL);
AttachThreadInput( dwThreadID, GetCurrentThreadId(), true);

SetWindowPos(hApp, HWND_TOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
SetWindowPos(hApp, HWND_NOTOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);

SetForegroundWindow(hApp);
SetActiveWindow(hApp);
SetFocus(hApp);

AttachThreadInput( dwThreadID, GetCurrentThreadId(), false);

I feel like I am missing an important gotcha when it comes to window switching. I know that only the foreground process can switch windows around but as my main Manager program is spawning and starting all the other processes which I need to control, I feel like it should be capable of moving these windows around. Any suggestions or advice is appreciated.

First step, read and understand this: http://blogs.msdn.com/b/oldnewthing/archive/2009/02/20/9435239.aspx — Adrian McCarthy, Sep 22 '10 at 18:14
Also: http://blogs.msdn.com/b/oldnewthing/archive/2008/08/01/8795860.aspx — Adrian McCarthy, Sep 22 '10 at 18:21
Adrian - Thanks for the articles, I have read them before and where I am confused is why don't I have SetForegroundWindow privileges in the first place? My Manager process spawns all the processes I will try to switch to. I don't know how to check if my process is the Foreground process. — micheal blunning, Sep 23 '10 at 01:06
In addition to those MSDN blogs by Raymond we now have [a StackOverflow answer by Raymond](http://stackoverflow.com/a/8081858/15639)! — MarkJ, Sep 25 '12 at 12:08

score 10 · Answer 1 · answered Aug 24 '12 at 05:42

I was having the same issue and I didn't want to mess up with threads. On experimenting I observed a simple hack to make SetForegroundWindow() work in the expected manner. Here is what I did:

Minimize the window if its not already minimized
Restore the minimized window
Call SetForegroundWindow(), and your window will be on top

score 7 · Accepted Answer · answered Sep 22 '10 at 18:19

7

Your AttachThreadInput() hack is (I think) a known way to defeat the focus stealing counter-measures in Windows. You are using the wrong handle though, you want to attach to the thread that currently has the focus. Which won't be hApp, you wouldn't need this code otherwise.

Use GetForegroundWindow() to get the handle to the window with the focus.

AttachThreadInput(
    GetWindowThreadProcessId(GetForegroundWindow(), NULL),
    GetCurrentThreadId(), TRUE
);

Although I think the 2nd argument needs to be thread ID of hApp. Because you don't want to shove your own window if I understood correctly. Not sure if that can work.

answered Sep 22 '10 at 18:19

Hans Passant

922,412
146
1,693
2,536

This is definitely a hack that I am using as a last resort, I am unsure why I would need to attach to the Foreground process since everything in the Foreground is a child of my Manager application. Perhaps something I am doing is causing to lose focus. Thank you for identifying the error, I really hope this was the issue! – micheal blunning Sep 23 '10 at 01:12
I think that this mostly solved my problem, I still have an occasional issue but what ended up doing was something like: for i 0 to 3 and !done attach to thread set as top most set as top detach if getforegroundwindow = app done = true – micheal blunning Sep 24 '10 at 23:07
2

This hack [can cause your program to hang](http://blogs.msdn.com/b/oldnewthing/archive/2008/08/01/8795860.aspx) – MarkJ Jan 19 '12 at 22:54

score 3 · Answer 3 · answered Oct 06 '15 at 11:36

The easiest solution in C# to bring a window in the foreground:

Once you have the handle for the window, you can simply call:

    SetWindowPos(handle, new IntPtr(0), 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_SHOWWINDOW);
    ShowWindow(handle, 5);
    SetForegroundWindow(handle);

    // If it is minimized, show the window
    if (IsIconic(handle))
    {
      ShowWindow(handle, 3);
    }

where

const int SWP_NOMOVE = 0x0002;
const int SWP_NOSIZE = 0x0001;
const int SWP_SHOWWINDOW = 0x0040;

score 2 · Answer 4 · edited Nov 15 '11 at 09:51

Some windows are locked with setforeground(...), you need to unlock them. This sequence is useful with any window:

HWND needTopWindow=FindWindow(TEXT("classname"), TEXT("window name"));

the classname and window name you can retrieve with ranorexspy from e.g. nanoware.cz

if(!::IsWindow(needTopWindow)) return;

BYTE keyState[256] = {0};
//to unlock SetForegroundWindow we need to imitate Alt pressing
if(::GetKeyboardState((LPBYTE)&keyState))
    {
    if(!(keyState[VK_MENU] & 0x80))
        {
        ::keybd_event(VK_MENU, 0, KEYEVENTF_EXTENDEDKEY | 0, 0);
        }
    }

    ::SetForegroundWindow(needTopWindow);

if(::GetKeyboardState((LPBYTE)&keyState))
    {
        if(!(keyState[VK_MENU] & 0x80))
        {
            ::keybd_event(VK_MENU, 0, KEYEVENTF_EXTENDEDKEY | KEYEVENTF_KEYUP, 0);
        }
    }


        DWORD dwThreadID = GetWindowThreadProcessId(needTopWindow, NULL);
        AttachThreadInput( dwThreadID, GetCurrentThreadId(), true);

        SetWindowPos(needTopWindow, HWND_TOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);
        SetWindowPos(needTopWindow, HWND_NOTOPMOST, NULL, NULL, NULL, NULL, SWP_NOMOVE | SWP_NOSIZE);

        SetForegroundWindow(needTopWindow);
        SetActiveWindow(needTopWindow);
        SetFocus(needTopWindow);

        AttachThreadInput( dwThreadID, GetCurrentThreadId(), false);

score 1 · Answer 5 · answered Sep 23 '10 at 06:36

1

We had a similar problem a couple of years ago. We could solve it by the following function call:

SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, SPIF_UPDATEINIFILE);

Give it a try. See the documentation here.

answered Sep 23 '10 at 06:36

Bill

11,595
6
44
52

I am setting ForegroundLocktimeout in the registry, is it the same thing? – micheal blunning Sep 24 '10 at 20:01
I have just called `SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, 0, SPIF_UPDATEINIFILE)` and it has set `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout` to zero. – Bill Sep 30 '10 at 07:47
You can also refer to this link for more help: http://www.codeproject.com/Tips/76427/How-to-bring-window-to-top-with-SetForegroundWindo – Ankur May 30 '16 at 11:58

score 0 · Answer 6 · answered Jul 24 '15 at 09:33

0

You also need to consider the chances of window being minimized. If the window or various application are minimized then SetForegroundWindow(hApp) won't work. To be safe use ShowWindow(hApp, 9); I prefer value 9. Have a look at its documentation and choose which you find fit for you.

answered Jul 24 '15 at 09:33

Pradeep Bogati

203
2
8

1

I prefer symbolic constants. Seriously, this is 2015, and you are **still** using magic numbers? What's so wrong with `SW_RESTORE`? – IInspectable Sep 30 '15 at 08:18

score 0 · Answer 7 · answered Sep 22 '10 at 18:21

0

Try pushing the other application windows to the background first.

Also its a bit strange that you use SetWindowPos (SWP) to push a window to the foreground then push it out of the forgreound before using SetForegroundWindow to bring it back foward. Personally I've always used the SWP method without any issue ... but I've always pushed the other windows to the bottom as well.

answered Sep 22 '10 at 18:21

Goz

61,365
24
124
204

Are you referring to the NOTOPMOST followed by TOPMOST? – micheal blunning Sep 23 '10 at 01:08

Win32 SetForegroundWindow unreliable

7 Answers7

Linked