AutoHotkey Community

The timeout option will not work if the MsgBox has the option 0x20000:


Probably not an AHK thing, but a Windows thing. But I think the documentation should reflect that fact.

Could you mention what the 0x20000 option is for?...without making me Google for the name of the constant?

It's in the documentation.
http://www.autohotkey.com/docs/commands/MsgBox.htm

...OK, but some "magic numbers" are not in AHK's Docs & I hate searching for something when the person using the magic number likely already knows what the number is for...

I don't know what a "default desktop" is but it showed same behavior on my system, using 131072 and 0x20000.

If you have multiple monitors/desktops, the default one is which ever one you set as default...otherwise it's the only one...

Can we isolate this to XP/Vista/7?...post your OSs...

I have Xp Sp 3 and this bug manifested

Why are you even using that option? Are you really using multiple desktops?

For those that don't know (i.e. most people), a desktop in this sense is a specific, rarely-used facility introduced in Windows 2000. By "rarely-used" I mean that the vast majority of users see only the Winlogon desktop, the default desktop which is shown when a user logs in, and the ScreenSaver desktop which isolates the screensaver (and UAC prompts) from applications on the default desktop. Each process can only be associated with a single desktop, and cannot associate with some other desktop if it owns any windows. (Note: AutoHotkey scripts always own at least one window, though it is usually hidden.)

It is possible for third-party applications (including AutoHotkey) to create and switch to a desktop, but since it isn't possible to move windows between these desktops, it isn't generally useful. (However, it could be useful for kiosk-like applications.)

Since a process can't directly create a window on any desktop other than the one it is associated with, the MB_DEFAULT_DESKTOP_ONLY option of MessageBox tells a system process (which resides on the default desktop) to create the message box window. You can confirm by using WinGet, var, ProcessName, MsgBoxTitle - on my system it shows csrss.exe. This must also be the reason no visual style is applied to the MsgBox (on my system).

I imagine the option is used by non-interactive services, which (probably) aren't associated with any desktop and therefore can't directly create any windows.

While a modal dialog box is on-screen, the process which owns it runs a modal message loop. Since this MsgBox isn't owned by the script, no messages will be processed by the script while it is waiting for MessageBox to return. This is evident in the script below:
Until the "Has timeout" box is closed, the "No timeout" box, the script's tray icon and any other windows owned by the script will not respond. As soon as the "Has timeout" box closes, the script processes the "begin timeout" message - two seconds later it closes the top-most dialog, which is the "No timeout" box. Note that even if it were to receive and process the "begin timeout" message while the "Has timeout" box is visible, it looks specifically for the top-most dialog owned by the script's process (to avoid closing the wrong window), so would never find the MsgBox owned by csrss.exe (ironically, the right window).
That is not what "desktop" means in this particular context.

A few corrections: UAC is running on Winlogon Desktop, aka Secure Desktop, not on Screen-saver Desktop. And Desktop is more of thread-specific, so a process can connect to multiple-desktops at the same time via multiple-threads, each of which can have its own windows. And, MB_DEFAULT_DESKTOP_ONLY is not exactly restricted to Default desktop.

I highly recommend using/experimenting Desktops, as it's a literally/truly multi-desktops utility. One unfortunate fact about it though is that aero can only be enabled on one Desktop (:limitation/restriction imposed by Windows).

Thanks for the explanations Lexikos and Sean.
I did think that desktop in that context meant monitor, but I knew something was a little off (like you said, no style is applied to the MsgBox).

Thanks. I only skimmed over the documentation.
Would you care to elaborate?
At least MB_SERVICE_NOTIFICATION is clear: "displays a message box on the current active desktop".
I tried and abandoned that long ago as I found it rather limited for general use (see "isn't generally useful" in my previous post) and slow. I also began to write Desktop.ahk, but stopped when I realised it was mostly a waste of time.

It's a bit cumbersome to explain about these as the policy around Logon Session was changed from Vista due to the security consideration. Essentially, when a user is about log-on, it was assigned a session (used to start from session 0), and creates one (and only one) interactive WindowStation, named WinSta0, which can accomodate GUIs through which an user can interact. BTW, a session can also have several other non-interactive WindowStations, which of course can't accomodate GUIs. And, this WinSta0 typically creates/has defaultly three desktops at the start, named Winlogon/Default/Screen-saver. (A process can be associated with only one WindowStation, BTW)

OTOH, from Vista on, session 0 is now exclusively associated only with services (and alike) and creates/has no interactive WindowStation, so, there exists no longer one like an interactive service.

BTW, I'm not sure why MB_DEFAULT_DESKTOP_ONLY was described that way, but, I suppose it was more like to exclude Winlogon/Screen-saver than to pin-down specifically Default. I suggest to experiment with desktops.exe. After launching it, create three more desktops (:whose name will be Sysinternals Desktop 1/2/3). Then, excute the following code in any of the desktops, Default or Sysinternals Desktop 1/2/3, and switch to other desktop and wait. You'll see the MsgBox there which is different from the desktop where the code was executed. Moreover, try to switch among the desktops without dismissing the MsgBox.

I suggest the 0x20000 option be removed from the documentation to avoid this type of confusion.

I second that.