Sign in to follow this  
Followers 0
Lilla

Autoit3-gui - How To Tell If Checked And Disabled

7 posts in this topic

Windows XP Home with SP1

AutoIt3-GUI v102.20

AutoIt v3 build 101 pub 11 mar 2004

How do I tell if CHECKED and DISABLED?

I tried this, but it doesn't work...

If GuiRead ($chk_test1) = $GUI_CHECKED + $GUI_DISABLE Then

Thank you,

Lilla

Some test code

=================

Dim $GUI_CHECKED=1, $GUI_UNCHECKED=4, $GUI_ENABLE=64, $GUI_DISABLE=128, $BS_AUTOCHECKBOX = 0x0003

Dim $chk_test1, $chk_test2

GUI()

Func GUI()

GuiCreate ('test', 100, 100)

$chk_test1 = GuiSetControl ("checkbox", 'Test chk1', 20, 20, 50, 20, $BS_AUTOCHECKBOX)

GuiSetControlEx (-1, $GUI_CHECKED)

GuiSetControlEx (-1, $GUI_DISABLE)

GuiSetControlNotify ()

$chk_test2 = GuiSetControl ("checkbox", 'Test chk2', 20, 40, 50, 20, $BS_AUTOCHECKBOX)

GuiSetControlEx (-1, $GUI_CHECKED)

GuiSetControlEx (-1, $GUI_ENABLE)

GuiSetControlNotify ()

While GuiMsg () > 0

$n = GuiRead ()

TEST1()

Wend

EndFunc

Func test1()

If GuiRead ($chk_test1) = $GUI_CHECKED Then

msgbox(0,'debug','chk_test1 is checked')

EndIf

If GuiRead ($chk_test1)= $GUI_CHECKED + $GUI_DISABLE Then

msgbox(0,'debug','chk_test1 is checked and disabled')

EndIf

EndFunc

Share this post


Link to post
Share on other sites



#2 ·  Posted (edited)

Try...

If BitAND(GuiRead($chk_test1),$GUI_CHECKED + $GUI_DISABLE) = $GUI_CHECKED + $GUI_DISABLE Then

I think??

Larry, thanks for the suggestion. I tried it but it doesn't work.

The following is true, and msgbox is displays, so GuiRead() doesn't seem to see the DISABLE attribute. It is set though, you can see it in the GUI display.

If GuiRead ($chk_test1) = $GUI_CHECKED Then

msgbox(0,'debug','chk_test1 is checked')

EndIf

Edited by Lilla

Share this post


Link to post
Share on other sites

Just one small comment...

Tracking the state of buttons (Hidden/Disabled, not necessarily Checked) should be something the script itself knows internally. Meaning, since it isn't something that can (Normally) be changed by outside forces, the script should know when/if it's changing such states and should store the data somewhere.

Basically what I'm saying is that under normal circumstances, if the script doesn't know the hidden/disabled state of any controls it would need to know that state for at some point, then there is a design flaw in the script.

Share this post


Link to post
Share on other sites

...  Meaning, since it isn't something that can (Normally) be changed by outside forces, the script should know when/if it's changing such states and should store the data somewhere.

Does ControlCommand count as "outside forces" or "internal forces" :D

Anyway, Valik has a point--but I would not go so far to say it is a design flaw. For simple scripts, I believe your design is best. However, I think the generally accepted way to program a complex GUI is to use a message loop like the following and track whenever state changes:

Opt("GUINotifyMode", 1);all controls notify by default

GuiCreate("Example", 200, 300)
$chk_test1 = GuiSetControl("checkbox", "foo", 50, 50)

Dim $state = 0;initially unchecked

GuiShow()
While 1
    sleep(100)
    $msg = GuiMsg(0)
    Select
    Case $msg = -3 ;close button clicked
        ExitLoop
    Case $msg =  $chk_test1
        $state = NOT $state;toggle
    EndSelect
WEnd

MsgBox(4096,"Info", "The checkbox state is: " & $state)
Exit

Use Mozilla | Take a look at My Disorganized AutoIt stuff | Very very old: AutoBuilder 11 Jan 2005 prototype I need to update my sig!

Share this post


Link to post
Share on other sites

Well, it is a design flaw in that ControlCommand aside, there is no normal way for average-Joe-user to change the disabled or hidden state of a script, so that means the script itself is changing those. If it needs that information, but makes no effort to store it, that's like saying you want to add 1 + 2 and not store the result in a variable, even though you need that result later on.

I was counting ControlCommand as external, by the way. It doesn't work on the GUI natively, which means potentially risky methods of run-time control identification must be taken to determine the instance of each control (Hard-coding that change in at compile time is prone to later modifications breaking the script, so I wouldn't count that as an option). That's a lot of work to go through to use ControlCommand, so it's most definitely not something commonly used on GUI's.

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

Well, it is a design flaw in that ControlCommand aside, there is no normal way for average-Joe-user to change the disabled or hidden state of a script, so that means the script itself is changing those.  If it needs that information, but makes no effort to store it, that's like saying you want to add 1 + 2 and not store the result in a variable, even though you need that result later on.

I was counting ControlCommand as external, by the way.  It doesn't work on the GUI natively, which means potentially risky methods of run-time control identification must be taken to determine the instance of each control (Hard-coding that change in at compile time is prone to later modifications breaking the script, so I wouldn't count that as an option).  That's a lot of work to go through to use ControlCommand, so it's most definitely not something commonly used on GUI's.

In the REAL code the user can check/uncheck that field, depending on what is going on at the time.

There is a list of check boxes and radio boxes. Some of them cannot be combined. So there is the concept of sets. Boxes that do not apply to the active set are disabled (or sometimes hidden). Most of the boxes are part of more than one set.

If there were a way to read the attributes that would be the easiest way.

But since that isn't possible, then of course I can track the attributes in my While-Wend loop.

Thanks for helping me determine the direction I need to go.

Thanks for your help (again!),

Lilla

Edited by Lilla

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