AutoHotkey Community

WinActivate
Activates the specified window (makes it foremost).

f6::
   MouseGetPos,,,mhwnd
   WinSet, bottom,, ahk_id %mhwnd%
return

f7::
   MouseGetPos,,,mhwnd
   WinActivate, ahk_id %mhwnd%
return

f8::
   MouseGetPos,,,mhwnd
   DllCall("SetForegroundWindow", "uInt", mhwnd)
return

f9::
   MouseGetPos,,,mhwnd
   MsgBox, % DllCall("SetForegroundWindow", "uInt", mhwnd)
return

f10::
   MouseGetPos,,,mhwnd
   DllCall("BringWindowToTop", "uInt", mhwnd)
return

Bottom: Sends a window to the bottom of stack; that is, beneath all other windows. The effect is similar to pressing Alt-Escape. For example: WinSet, Bottom,, WinTitle.

guest3456 wrote:... the window is now at bottom, but its still 'active' according to windows and will still accepts keyboard input.

Winactivate wrote:If a matching window is already active, that window will be kept active rather than activating any other matching window beneath it.

	if (aTargetWindow == orig_foreground_wnd) // It's already the active window.
		return aTargetWindow;

If a matching window is already active, that window's state and position in the z-order will not be changed.

just me wrote:

guest3456 wrote:... the window is now at bottom, but its still 'active' according to windows and will still accepts keyboard input.

Winactivate wrote:If a matching window is already active, that window will be kept active rather than activating any other matching window beneath it.

In other words, AHK does nothing in this case.

Code: Select all

	if (aTargetWindow == orig_foreground_wnd) // It's already the active window.
		return aTargetWindow;

This might be more clear though:

If a matching window is already active, that window's state and position in the z-order will not be changed.

guest3456 wrote:any idea why F8 fails but F9 works?

just me wrote:I think I got it. AFAICS

Code: Select all

DllCall("SetForegroundWindow", "uInt", mhwnd)

behaves the identically in both cases. But the MsgBox in F9 steals the focus from the active notepad window. After the MsgBox is closed, the notepad window is moved to the top, probably by the system.

WinActivate does not guarantee bringing the window foremost, it just guarantees that the window is 'active'

Six attempts will be made to activate the target window over the course of 60ms. Thus, it is usually unnecessary to follow WinActivate with WinWaitActive or IfWinNotActive.

because a modal window (the msgbox) was closed and so it brings the active window to foreground?

lexikos wrote:It tries very hard, and sometimes that is enough.

lexikos wrote:By "the active window", I assume you mean Notepad, but the MsgBox is the active window. When it is closed, the OS activates another window and (sometimes) simultaneously brings it to the foreground.

The same thing will happen if you replace MsgBox with Gui Show followed by Gui Destroy, or Run cmd /c exit.

lexikos wrote:To bring the window to top if it's already active, or to try to activate the window when SetForegroundWindow fails? The former change in behaviour might not be warranted or desired by everyone.

just me wrote:The whole issue is caused by performing WinSet, Bottom for the active window and trying to activate the same window after that while it is still active. IMO, it seems to be reasonable that you have to perform WinSet, Top after or instead of WinActivate to move the window to the top again in this special case.