Ok, so here is a VERY simple script:
rollout checkbox_test "Checkbox Test"
(
checkbox test "Test"
timer clock "Clock"
interval:500 active:false
on clock tick do
(
print "Tick"
)
on test changed false do
(
print "OK"
clock.active = false
)
on test changed true do
(
clock.active = true
)
)
createdialog checkbox_test 100 100 100 100
I am HIGHLY interested why when unchecking the checkbox, no “OK” is printed in the listener BUT the clock will be deactivated! Any ideas? I hate to say this, but it really looks like a bug to me?
Youre not using the checkbox ui item event correctly. You don’t need an event for each state, as the current checkbox value is passed in the event variable. Since you have specified two, you have overwritten the first changed event with the second ,thus you don’t see the OK printed. All you actually need is
on test changed state do
(
clock.active = state
)
Thanks. I know that I should use the changed state method like you said, but I’m just wondering why obviously the script reads the clock.active = false (as the clock stops to tick when unchecking the checkbox) BUT NOT the print “OK”. That is what I don’t understand.
OK. that’s what happens…
the only correct syntax for change checkbox state event handle is “on checkbox changed state do” where state is a changed value. it’s a OUT parameter of this handle.
in you sample with two handles (“test changed false” and “test changed true”) the second one overrides the first and only second works. but “true” works as out parameter of the second handle, and takes values TRUE or FALSE:
check yourself:
try(destroydialog checkbox_test) catch()
rollout checkbox_test "Checkbox Test"
(
checkbox test "Test"
timer clock "Clock" interval:500 active:false
on clock tick do print "Tick"
on test changed true do
(
format "state: %
" true
clock.active = true
)
)
createdialog checkbox_test
does it make sense now?
so the mxs allows to redefine “true” and “false” by any value in the local scope. that’s why i always use alternative “on” and “off” instead of “true” and “false”. see:
(
true = "a"
false = "b"
)
(
on = "a"
)
(
off = "b"
)
and there is a little sample of ‘funny scripting’:
struct A(true = false, false = true)
Ok, it’s kind of weird a little bit, but I do understand. So in this case, “true” actually works the same as “state”. But “false” does not work at all.
The word you type in after the name of the word “changed” is not the state that it’s changing to – it’s simply the name of a variable that CONTAINS the state. You could do “on test changed Labrador do” and then have “print Labrador” and you’d see “true” when the button was checked and “false” when the button was unchecked. So effectively you have two “when the checkbox changes” functions if you have two “on test changed VAR do”.
Using the words “true” and “false” as that variable can cause you all sorts of headaches.
I exclusively use dog-breed names. Keeps it simple.
… or geographical names. i have couple nice one: Thiruvananthapuram and Guadalquivir.
keep everything simple!
… if you would like a Russian geographic there is a good one – Mezhdurechensk.
it’s simple to write and easy to remember.
My old rugby team used to use alcoholic drinks as the “code” when doing thrown line-outs – Beer or Cider meant a short pass, wine meant to the middle, and spirits meant a long throw (ironically). The problem was that people would boast about how much they knew about drinking by shouting stuff no has heard of.
“GOLDSCHLAGER!”
“Is that a spirit or a German beer?!”
As such, I stick to dogs.
something German for sure
Haha, that’s funny. Great. Now I know it’s just a variable. Thanks for clarification.
I think the help explains it pretty good, no?
Events
on <checkbox> changed <arg> do <expr>
Called when the user clicks the check box to check or uncheck it. The <arg> argument contains the new state of the check box, on ( true ) or off ( false ).
NoteThe <arg> is a local variable in the context of the event handler – you can use it inside the handler to act according to the new state of the checkbox.
As for variable declarations, you know its one of my scripts when ‘bumholes’ gets printed periodically to the listener.
True. It’s just that sometimes you pick up parts of old code and you think that is the way to go without further thinking. Funny, I was already using the correct “on checkbox changed state do” method in other parts of my code, but in this case, for some reason, I did it the wrong way. Stupid me. And I was irritated why the “OK” was not printed while the scipts seemed to read the other part of the clause. Maybe I was really not fully aware about the meaning. I’m using the help a lot and read a lot stuff in there. I was sure there was a reason why it works the way it works, and that of course is the way I’m dealing with problems: Finding out on my own, as there is a reason for 99%. This time, I definitely rushed it.