Problem with GUISetState

[erebus]

Hello all and congratulations for the excellent work already done.

I have discovered AutoIT3 a few months ago and I am really amazed by its power and the simple syntax. A few days ago I decided to try the GUI beta.

I started to write a script with many GUI commands (mostly to test it and learn the new features). I have discovered a bug (? if it really is) in the GUISetState command. Watch this code:

Case $msg = $GUI_EVENT_CLOSE
       GuiSetState(@SW_DISABLE)
       $quit = MsgBox(19,"Exit the program", "Are you sure?")
          If $quit = 6 Then
             ExitLoop
          Else
             GuiSwitch($mainwin)
             GuiSetState()
          EndIf

The idea is when the MsgBox appears, the user to be unable to click on anything on the main GUI window. If he cancels the program's termination, the GUI initial state should be restored.

I have tried either with the GUISwitch command or without it but the effect is the same: it seems like the script restores the next minimized open window and sends the SW_ENABLE state there instead to AutoIT's GUI window. Any ideas?

Thank you very much for your time and I apologize if this has already been reported.

[Valik]

You aren't sending @SW_ENABLE, you just call GuiSetState() which by default, only calls @SW_SHOW. I don't think this is what you are wanting...

[erebus]

You aren't sending @SW_ENABLE, you just call GuiSetState() which by default, only calls @SW_SHOW.  I don't think this is what you are wanting...

<{POST_SNAPBACK}>

Let's test a bit...

Case $msg = $GUI_EVENT_CLOSE
       GuiSetState(@SW_DISABLE)
       $quit = MsgBox(19,"Quit", "Are you sure?")
          If $quit = 6 Then
             ExitLoop
          Else
             GuiSetState(@SW_ENABLE)
          EndIf

The result is similar to the above problem: If the user presses Cancel of No the GUI is enabled again, however the script continues to activate the next open window instead of returning to the GUI. The only way to solve this is by adding a WinActivate command so as to give focus again to the GUI window (however this occasionally produces an ugly screen refresh to the GUI). Is this a normal behaviour?

[SlimShady]

the script continues to activate the next open window instead of returning to the GUI. The only way to solve this is by adding a WinActivate command so as to give focus again to the GUI window (however this occasionally produces an ugly screen refresh to the GUI).

Exactly what I have experienced with a script I made.

[Holger]

Maybe this is the answer why:

"...A window must be enabled before it can be activated. For example, if an application is displaying a modeless dialog box and has disabled its main window, the application must enable the main window before destroying the dialog box. Otherwise, another window will receive the keyboard focus and be activated. If a child window is disabled, it is ignored when the system tries to determine which window should receive mouse messages...."

From MSDN-library->"EnableWindow"

Edit:: there are 2 possibilities at the moment:

1.) hide the window and then show it again:

$mainwin = GUICreate("test")

GUISetState()
while 1
    $msg=Guigetmsg()
    if $msg = -3 Then
        GuiSetState(@SW_DISABLE)
        $quit = MsgBox(19,"Exit the program", "Are you sure?")
        If $quit = 6 Then
            ExitLoop
        Else
            GuiSetState(@SW_HIDE)
            GuiSetState(@SW_SHOW)
        EndIf
    Endif
WEnd

2.) you write your own "msgbox"-window as a child-window, something like:

#include "GUIConstants.au3"

$parentgui = GUICreate("Parent",400,300)
GUISetState(@SW_SHOW)

$childgui = GUICreate("Child",340,120,-1,-1,BitOr($WS_POPUP,$WS_CAPTION,$WS_SYSMENU),-1,$parentgui)
GUISetState(@SW_SHOW)
GUISwitch($parentgui)
GUISetState(@SW_DISABLE)

While 1
    $msg = GUIGetMsg(1)

    $ctrlmsg = $msg[0]
    $win = $msg[1]
    $posx = $msg[3]
    $posy = $msg[4]
  
    Select
        Case $ctrlmsg = $GUI_EVENT_CLOSE And $win = $parentgui
            ExitLoop
        Case $ctrlmsg = $GUI_EVENT_CLOSE And $win = $childgui
            GUISwitch($parentgui)
            GUISetState(@SW_ENABLE)
            GUISwitch($childgui)
            GUISetState(@SW_HIDE)
    EndSelect
WEnd

GUIDelete()

Exit

so long

Edited October 28, 2004 by Holger

[erebus]

Maybe this is the answer why:

"...A window must be enabled before it can be activated. For example, if an application is displaying a modeless dialog box and has disabled its main window, the application must enable the main window before destroying the dialog box. Otherwise, another window will receive the keyboard focus and be activated. If a child window is disabled, it is ignored when the system tries to determine which window should receive mouse messages...."

From MSDN-library->"EnableWindow"

This is a very good explanation, however I 've noticed the following:

Even if I reverse my code to

WinActivate ($app & " " & $ver)   
             GuiSetState(@SW_ENABLE)

...the "next" open window continues to be called by my script (even for some milliseconds before the WinActivate command is executed; however it is visible if for instance you keep the ESC pressed for some seconds). Is that a normal behaviour, or should AutoIT restore the disabled GUI window automatically upon a "SW_ENABLE" command?

Just a thought, don't shoot...

[Holger]

Hmmm...I think it's normal cause you have stil the keyboard focus (cause of ESC-pressing).

I'm no Windows-expert...

I don't know if it should also be popup if you enable it.

@jpm: if you read this: what do you think about it?

I have no plan at the moment, but for me it's 'right'/normal/default window behaviour.

[jpm]

The @SW_DISABLE /msgbox/@SW_ENABLE change the order in which windows is giving the focus to the window GUI. So the WinActivate is needed to have the the GUI activate.

I am sure that @SW_ENABLE has nothing to do which this reordering so I think if somebody use the DISABLE/ window creation has msgbox /ENABLE it has to manage the activation by WinActivate