Sign in to follow this  
Followers 0
Just_Plain_Cool

@SW_DISALBE/@SW_ENABLE minimizing window?

9 posts in this topic

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 :(

Share this post


Link to post
Share on other sites



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 :(

Share this post


Link to post
Share on other sites

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 :(

Share this post


Link to post
Share on other sites

#4 ·  Posted (edited)

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 by improbability_paradox

Share this post


Link to post
Share on other sites

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.

George

Question about decompiling code? Read the decompiling FAQ and don't bother posting the question in the forums.

Be sure to read and follow the forum rules. -AKA the AutoIt Reading and Comprehension Skills test.***

The PCRE (Regular Expression) ToolKit for AutoIT - (Updated Oct 20, 2011 ver:3.0.1.13) - Please update your current version before filing any bug reports. The installer now includes both 32 and 64 bit versions. No change in version number.

Visit my Blog .. currently not active but it will soon be resplendent with news and views. Also please remove any links you may have to my website. it is soon to be closed and replaced with something else.

"Old age and treachery will always overcome youth and skill!"

Share this post


Link to post
Share on other sites

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)


NEWHeader1.png

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

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 by Sunaj

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0