Gui "focus" weirdness

[JBensimon]

I have a longish script that creates and displays various GUI dialogs in response to certain hotkeys, and I've observed a strange behavior: when a GUI is displayed (Gui, Show ...), it appears without the current accent color in its title bar (i.e. its title bar is white, making it look as if it doesn't have focus), yet it does have focus, based on the fact that I can immediately interact with it via the keyboard and that Window Spy reports it as the currently active window. The white title bar remains even if I click into the GUI, or move/maximize/resize it, but I do get the accent color back if I either minimize and restore the GUI, or if I click some other window and then click back into the GUI. Programmatically, I can force the accent color to appear if, following Gui, Show, I WinActivate some other window (I use the script's own hidden window since I know that always exists) and immediately WinActivate the GUI, but that's not ideal because it affects which other window will regain focus once the GUI is closed (because I've messed with the z-order).

Interestingly, if I break one of these GUIs out into its own standalone script (still displaying it in response to a hotkey), I don't observe this accent color issue, yet there is nothing in the full script that I can think of (such as timers or other asynchronous actions) that explains it. I've also confirmed the issue remains with the latest AHK version (I was on 1.33.x) because there was some mention in one of the later release notes about Gui, Show and focus behavior having been addressed.

Have you seen this behavior? Ideas/thoughts?

Thanks!

JB

[mikeyww]

If you post your script below, then various readers can test, confirm, and examine your findings.

[JBensimon]

I couldn't very well post a 3200+ lines script, so I did some experimenting and tracked down what appears to be the cause: the combination of #WinActivateForce and of creating & showing a GUI in response to a hotkey produces the behavior I described (although I've also seen it without the GUI being created from a hotkey, but more rarely -- #WinActivateForce is the key element).

Code: Select all

#SingleInstance Force
#WinActivateForce
SetBatchLines, -1
Return

^+q::
Gui, Add, Edit, x10 y10 w400 h200
Gui, Show,, Accent Color Missing From Title Bar
Return

GuiClose:
GuiEscape:
Gui, Destroy
Return

Pressing Ctrl+Shift+Q will consistently bring up a dialog with focus (it is the active window), but it's missing the title bar accent color (and the matching 1-pixel window frame) and therefore appears inactive. As I mentioned earlier, giving focus to another window and coming back to the GUI will restore the accent color, as would minimizing and restoring the GUI (same idea). Interestingly, once that's been done once, closing and later recreating the GUI via the hotkey will display it with the accent color, but restarting the script of course brings back the original behavior.

GUI1.png (7.84 KiB) Viewed 633 times

GUI2.png (7.12 KiB) Viewed 633 times

JB

[mikeyww]

I saw the issue in testing with your script, not sure why it happens, but #WinActivateForce is uncommonly needed in scripts, so perhaps your script will work without it.

[JBensimon]

Yes, the script (like most scripts) does work without #WinActivateForce, but this particular one at times activates local windows above full-screen remote sessions (various technologies: RDP, Citrix, VMware View) and, subjectively, it feels more immediate (and possibly even more reliable) with that setting.

[JBensimon]

For what it's worth, here's the workaround I settled on to correct a new GUI's accent color without affecting the z-order: rather than temporarily give focus to an existing window before giving it back to the GUI, I give focus to a new ("invisible") window and immediately destroy it (by calling this function after the initial GUI, Show):

Code: Select all

ForceAccentColor()	; creates & destroys invisible GUI to fix
{					; the #WinActivateForce accent color issue
  Gui, XX:New, -SysMenu -Caption +ToolWindow
  Gui, XX:Show, w0 h0
  Gui, XX:Destroy
}

Works every time, and is completely undetectable even on a slow machine.

[mikeyww]

Thanks for sharing the solution.

[jrssd]

Thank you JBensimon!

This issue was driving me crazy for over a day. I had cut and pasted the directives from a big script where #WinActivateForce was actually needed to a small script where it was "breaking" the 1st and only GUI invoked. Even popping up a MsgBox before invoking my GUI was enough to "fix" the problem.

Thanks again!