Nils2000
28th November 2003 16:53 UTC

BringToFront doesn't work on XP
Hi,

BringToFront doesn't work on WinXP. It only makes the taskbar appear and the icon of the window blink.

Has this to do with the documentation of the Win-API Function
SetForegroundWindow ?
Here's an extract:
[...]
Windows NT 5.0 and later: An application cannot force a window to the foreground while the user is working with another window. Instead, SetForegroundWindow will activate the window (see SetActiveWindow) and call theFlashWindowEx function to notify the user.
[...]

Thanks for any help.

kichik
28th November 2003 17:02 UTC

Yes, that's the bit of information that's related to it and explains it perfectly. There is no easy method I know about that you can use to override this. Frankly, I think that's a good thing. As a user, I hate it when Windows pop-up and require my attention while I'm doing something totally unrelated.

Nils2000
28th November 2003 17:14 UTC

I totally agree with you to that. However, I wonder how some MS-Applications like Outlook manage to penetrate me when I'm synchronizing my eMail-Accounts. Well, I don't believe this is some undocumented functionality, of which MS-Applications take advantage ;-)

kichik
28th November 2003 17:23 UTC

Well... If you really want to do that, you can install a global hook which, on your command, will set the foreground window to your application. As a global hook will be injected into every process and therefore will be run under each of them, including the one that has the foreground window, you should be able to do that.

Also, new windows which are shown using SW_SHOWNORMAL, should pop-up on front. Outlook and friends might just create the window every time to have it pop-up. If that is true, you can create a small window that will never really show on the screen, but get the foreground property and will therefore be able to set it to your window.

Nils2000
1st December 2003 09:28 UTC

In that special case I'ld really like to do that, because when installing software, one shouldn't work with other programms. I think this is stated somewhere on the first dialog of the installer. The problem occurs because there is another application, which is installed from the installer. This application pops up a Readme and the application folder which overlap the installer.

Isn't there a new window created when I use MUI_INSTALLOPTIONS_DISPLAY ?

kichik
1st December 2003 13:08 UTC

Setup wizards say a lot of things ;) It usually isn't really nessacry to close all other programs.

Is there no command line switch that will tell the second installer to not pop-up the readme and the folder?

A new window is created for InstallOptions pages, but it's not a top level window.

kichik
11th December 2003 13:35 UTC

I can't believe I forgot about this (the first part tells you how to do what you want to do):

http://www.installsite.org/pages/en/isp_ext.htm

Nils2000
11th December 2003 17:31 UTC

Thanks,
I've tried it, but it didn't work :(

So I've done a bit more research and found another method:
HWND theForegroundWnd = ::GetForegroundWindow();
::AttachThreadInput(::GetWindowThreadProcessId( theForegroundWnd, NULL), ::GetCurrentThreadId(), TRUE);
BOOL retVal = ::SetForegroundWindow( hwndParent );
::AttachThreadInput( ::GetWindowThreadProcessId( theForegroundWnd, NULL), ::GetCurrentThreadId(), FALSE);

but it didn't work either. I've no clue. Somewhere I've read that MS has disabled both methods but I don't know if it's true.

kichik
12th December 2003 17:01 UTC

Well, the AttachThreadInput trick works for Banner, but for threads in the same process. Maybe the combination of both will do the trick.

Anders
12th December 2003 19:09 UTC

Originally posted by Nils2000
Thanks,
I've tried it, but it didn't work :(

So I've done a bit more research and found another method:
HWND theForegroundWnd = ::GetForegroundWindow();
::AttachThreadInput(::GetWindowThreadProcessId( theForegroundWnd, NULL), ::GetCurrentThreadId(), TRUE);
BOOL retVal = ::SetForegroundWindow( hwndParent );
::AttachThreadInput( ::GetWindowThreadProcessId( theForegroundWnd, NULL), ::GetCurrentThreadId(), FALSE);

but it didn't work either. I've no clue. Somewhere I've read that MS has disabled both methods but I don't know if it's true.

Nils2000
15th December 2003 09:06 UTC

::SetFocus doesn't make a change with the AttachThread-method.

@kichik:
SystemParametersInfo(...) fails with error-code ERROR_ACCESS_DENIED, when it is used to set the parameter. Reading the parameter works fine. So I don't think a combination of both methods would make any change.

kichik
15th December 2003 13:58 UTC

According to MSDN:

The calling thread must be able to change the foreground window, otherwise the call fails.