Autoit3-gui - How To Tell If Checked And Disabled

[Lilla]

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

[Lilla]

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 May 1, 2004 by Lilla

[Valik]

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.

[CyberSlug]

...  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"

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

[Jon]

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

[Valik]

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.

[Lilla]

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 May 1, 2004 by Lilla