Nach MsgBox wird Window Busy Topic is solved

[Gerdi]

AHK und/oder das Betriebssystem haben ein seltsames Verhalten bei folgendem Skript:

Code: Select all

Gui, Show, Center  h270 w322

MsgBox, 8256,AHK-Version, %A_AhkVersion% ,2
sleep 20000
ListLines
#q::
ExitApp
return

Beide Fenster lassen sich nicht mit der Maus manipulieren.

#q beendet das Skript.

[just me]

Moin,

die MsgBox lässt sich hier schon mit der Maus ansprechen, solange sie angezeigt wird.

Ich glaube, dieses Problem wurde schon diskutiert. Es hängt meiner Erinnerung nach mit dem Timeout zusammen. AHK will aus irgendwelchen Gründen die totale Kontrolle behalten, auch während eine Msgbox angezeigt wird. Für den Timeout wird deshalb nicht die (von Microsoft nicht offiziell dokumentierte) Funktion MessageBoxTimeout() verwendet. AHK simuliert das mit einem internen Timer. Das scheint bei neueren Windowsversionen Probleme zu bereiten, wenn eine MsgBox nach Zeitablauf automatisch geschlossen wird, für die der Typ MB_TASKMODAL (0x00002000L) gesetzt wurde. Der Fehler tritt nicht auf, wenn direkt die Funktion MessageBoxTimeout per DllCall aufgerufen wird:

Code: Select all

Gui, Show, Center  h270 w322

MessageBoxTimeout(0, A_AhkVersion, "AHK-Version", 8256, 2000)
sleep 20000
ListLines
Return
GuiClose:
#q::
ExitApp
return

MessageBoxTimeout(Owner, Text, Title, Type, Time) {
   Return DllCall("MessageBoxTimeout", "Ptr", Owner, "Str", Text, "Str", Title, "UInt", Type, "UShort", 0, "UInt", Time, "Int")
}

[nnnik]

Grund dafür dass AHK die Kontrolle behalten will ist, dass es immer auf Hooks antworten können muss.

[just me]

Ja, ist mir klar, doch irgendwie läuft ja bei dieser Parameterkombination in AHK offensichtlich etwas falsch.

[Gerdi]

Danke euch beiden,

fuer mich war aergerlich, dass ich in einem laengeren Skript mehere Tage nach dem Fehler suchte
und dann nur zufaellig auf die fehlerhafte MSGBox-Option gekommen bin.

JustMe Deine Fehlerumschiffung funktioniert tadellos.

[Gerdi]

Es muesste doch moeglich sein, dass intern AHK mit einem eigenen Timer auf den Timeout wartet,
die MsgBox letztendlich mit einem Betriebsystem Befehl schliesst, sodass die Fenster nicht mehr busy werden!?!

[just me]

Moin Gerdi,

genau das tut AHK. Für den Fall, dass die MsgBox aufgrund des Typs 8192 (Task-Modal) vorhandene Anwendungsfenster blockt, entsteht dabei aber anscheinend (zumindest manchmal) ein Zustand, der die Anwendungsfenster nicht wieder aktiviert.