@SW_DISALBE/@SW_ENABLE minimizing window?

[Just_Plain_Cool]

First attempt at writing a script using a GUI. Very impressive addition to AutoIt! I'm almost good to go, but I have run into a problem...

I'm sure I am missing something simple, but...

The following code is called when a user selects "About..." from a menu in my GUI. The GUI is being disabled when the splash screen is displayed. However, when they press the spacebar to return to the program, the GUI is re-enabled but minimized.

Func AboutScreen()
    GUISetState(@SW_DISABLE)
    SplashTextOn("About...", @CRLF & $g_szVersion & @CRLF & @CRLF & "Copyright " & Chr(169) & " 2005 by JPC" & @CRLF & @CRLF & "Press Space to Continue..." , 275, 140, -1, -1, 16, "", 12, 400)
    WinActivate("About...")
    HotKeySet("{SPACE}", "TurnOffSpash")
EndFunc

Func TurnOffSpash()
    SplashOff()
    GUISetState(@SW_ENABLE)
    HotKeySet("{SPACE}")
EndFunc

Any and all help appreciated...

JPC

[jpm]

I assume you see this behaviour running under Scite editor.

I don't now why this interaction occured. But if you run the script alone it is OK.

to avoid this behaviour you can add a GUISetState() after your GuiSetState(@SW_ENABLE) which will force the focus to come back when you run under Scite

[Just_Plain_Cool]

I assume you see this behaviour running under Scite editor.

I don't now why this interaction occured. But if you run the script alone it is OK.

to avoid this behaviour you can add a GUISetState() after your GuiSetState(@SW_ENABLE) which will force the focus to come back when you run under Scite

<{POST_SNAPBACK}>

Hi JPM,

You are exactly correct. I was seeing it while running under the Scite editor. When I compiled it and ran it alone, all is fine. I did need to add a WinActivate since I had used one on the Splash.

Thanks for your help,

JPC

[improbability_paradox]

Hi JPM,

You are exactly correct. I was seeing it while running under the Scite editor. When I compiled it and ran it alone, all is fine. I did need to add a WinActivate since I had used one on the Splash.

Thanks for your help,

JPC

I know that I am resurrecting a post which is over a year, old, but I am experiencing the same problem in my script. I searched the forum and came up with this thread and one other referring to this issue. The problem first occurred when running in Scite, but even after the script was compiled it persisted. My script is fairly long, so I am only including a snippet which produces the problem. Obviously, the GUI is created prior to this part of the script.

if $RMCList=True then 
    GUISetState(@SW_DISABLE,$Form1)
;TrayItemSetState($TrayCallHelp, $TRAY_DISABLE)
;TrayItemSetState($TrayExit, $TRAY_DISABLE)
    $NTN = InputBox($TrList[$listselected][4],@CRLF & "Please enter a name to define this Event," & @CRLF & "and Click OK to Accept or Cancel to Abort.",""," ","240","165","-1","-1")
    Select
        Case @error=1
            ...
        Case not($NTN="")
            ...
        Case Else
            ...
    EndSelect
    $RMCList=False
    GUISetState(@SW_ENABLE,$Form1)
;TrayItemSetState($TrayCallHelp, $TRAY_ENABLE)
;TrayItemSetState($TrayExit, $TRAY_ENABLE)
EndIf

I also took out the code from within the "Select" portion, as it references arrays that aren't previously declared when using this snippet by itself. (and anyway they really don't have anything to do with the problem) Even when I insert the code GUISetState(@SW_SHOW) after GUISetState(@SW_ENABLE,$Form1), the GUI still ends up in the background. I can solve this by using winactivate, but it isn't the most elegant solution as the GUI then seems to need to refresh itself (everything contained in it flickers for a brief moment). Any ideas?

Using AutoIT 3.2.0.1

Thanks

Edit! A few more details I just discovered...

GUISetState(@SW_RESTORE) does the same as winactivate($Form1), in that it causes the GUI to be displayed again, but the contents seem to be refreshed (or at least flicker briefly)

If I eliminate the line GUISetState(@SW_ENABLE,$Form1) the GUI still disappears. It seems, then, that the problem is due to two factors. One is the GUI being disabled, while the other is the InputBox closing. The other thread said that this could happen with a MsgBox closing and disabled GUI, so I would assume that this is a bug in AutoIT.

I may end up creating a new GUI to serve the same purpose of the InputBox, and just use that instead of the conventional InputBox. I could probably solve the problem that way, unless anyone has any other ideas?

Edit #2:

OK, I just tested this using another GUI created by me instead of the InputBox. The same thing happened. That is, if the first GUI is disabled, and the second GUI closes, the first GUI is sent behind any other active windows (Could have been minimized, as I didn't check). This occurred with a compiled script. When the original GUI was re-enabled, it was still not visible until a winactivate or GUISetState(@SW_RESTORE). I am definitely thinking that this is a bug in AutoIT. Can anyone else confirm this behavior for me?

Edited November 18, 2006 by improbability_paradox

[GEOSoft]

I know that I am resurrecting a post which is over a year, old, but I am experiencing the same problem in my script. I searched the forum and came up with this thread and one other referring to this issue. The problem first occurred when running in Scite, but even after the script was compiled it persisted. My script is fairly long, so I am only including a snippet which produces the problem. Obviously, the GUI is created prior to this part of the script.

if $RMCList=True then 
    GUISetState(@SW_DISABLE,$Form1)
;TrayItemSetState($TrayCallHelp, $TRAY_DISABLE)
;TrayItemSetState($TrayExit, $TRAY_DISABLE)
    $NTN = InputBox($TrList[$listselected][4],@CRLF & "Please enter a name to define this Event," & @CRLF & "and Click OK to Accept or Cancel to Abort.",""," ","240","165","-1","-1")
    Select
        Case @error=1
            ...
        Case not($NTN="")
            ...
        Case Else
            ...
    EndSelect
    $RMCList=False
    GUISetState(@SW_ENABLE,$Form1)
;TrayItemSetState($TrayCallHelp, $TRAY_ENABLE)
;TrayItemSetState($TrayExit, $TRAY_ENABLE)
EndIf

I also took out the code from within the "Select" portion, as it references arrays that aren't previously declared when using this snippet by itself. (and anyway they really don't have anything to do with the problem) Even when I insert the code GUISetState(@SW_SHOW) after GUISetState(@SW_ENABLE,$Form1), the GUI still ends up in the background. I can solve this by using winactivate, but it isn't the most elegant solution as the GUI then seems to need to refresh itself (everything contained in it flickers for a brief moment). Any ideas?

Using AutoIT 3.2.0.1

Thanks

Edit! A few more details I just discovered...

GUISetState(@SW_RESTORE) does the same as winactivate($Form1), in that it causes the GUI to be displayed again, but the contents seem to be refreshed (or at least flicker briefly)

If I eliminate the line GUISetState(@SW_ENABLE,$Form1) the GUI still disappears. It seems, then, that the problem is due to two factors. One is the GUI being disabled, while the other is the InputBox closing. The other thread said that this could happen with a MsgBox closing and disabled GUI, so I would assume that this is a bug in AutoIT.

I may end up creating a new GUI to serve the same purpose of the InputBox, and just use that instead of the conventional InputBox. I could probably solve the problem that way, unless anyone has any other ideas?

Edit #2:

OK, I just tested this using another GUI created by me instead of the InputBox. The same thing happened. That is, if the first GUI is disabled, and the second GUI closes, the first GUI is sent behind any other active windows (Could have been minimized, as I didn't check). This occurred with a compiled script. When the original GUI was re-enabled, it was still not visible until a winactivate or GUISetState(@SW_RESTORE). I am definitely thinking that this is a bug in AutoIT. Can anyone else confirm this behavior for me?

No ideas but I'll do some testing since this may be related to a problem I reported in the Bug forum. I'll see if Winactivate will solve that problem.

[Valuater]

No ideas but I'll do some testing since this may be related to a problem I reported in the Bug forum. I'll see if Winactivate will solve that problem.

yours was not a bug problem nor related to this post.... you just didn't use GUISetState() correctly

8)

[Sunaj]

Maybe this thread can be of help to people having problems with opening msgboxes..etc. while wanting the main GUI 'disabled'. The method used in the thread is simply to use DllCall and bind the opened msgbox..etc. to the main GUI. However, to get a splash screen to work one would need to find out the right DllCall, which could be a serious challenge.. Good luck

/Sunaj

Edited November 21, 2006 by Sunaj

[improbability_paradox]

Maybe this thread can be of help to people having problems with opening msgboxes..etc. while wanting the main GUI 'disabled'. The method used in the thread is simply to use DllCall and bind the opened msgbox..etc. to the main GUI. However, to get a splash screen to work one would need to find out the right DllCall, which could be a serious challenge.. Good luck

/Sunaj

A workable solution! I tested your example script and it does exactly what I was looking to do. Do you know what the proper syntax is for a DllCall to create an InputBox? Thanks!

On another note, the following link is to the bug report I made on the issue I have detailed in my previous post.

http://www.autoitscript.com/forum/index.php?showtopic=36476

[Sunaj]

Happy to help! I spent a LONG time with this particular issue ( @SW_DISABLE causing the GUI to move one place 'back' in the z-order of the currently open windows). Nice to see that you filed a bug on it - I'll try and fill in a bit of nfo from my own experience on it.

Anyways, I cannot seem to find a 'InputBox' call on MSDN? (spend 20m trying..) - the thing is that the place is STUFFED with information on strange sub-sub-sub features of Windows and frankly not overly userfriendly. Best advice is probably to spend -time- trawling MSDN? and maybe get help from other users (than me) on this forum... Send me msg if you succeed, working DllCalls are like small precious gems in AU3 context!

A workable solution! I tested your example script and it does exactly what I was looking to do. Do you know what the proper syntax is for a DllCall to create an InputBox? Thanks!

On another note, the following link is to the bug report I made on the issue I have detailed in my previous post.

http://www.autoitscript.com/forum/index.php?showtopic=36476