Radio-Button-Function OR Boolean-Ping-Pong

Agents, Actions and Automation
1

Check it out.tbx (54.0 KB) is a file that contains 1 note named “Check it out”.

“Check it out” has two User-KeyAttributes:

  • Check_A
  • Check_B

What’s the Goal?

The goal is to have some sort of a “radio-button-function”, i.e.: if Check_A is checked, Check_B should be unchecked and vice versa.

1. Check_B - easy: works!

2. Check_A: works too!

3. Check_B (again): does not work!

Why does it not work?

Enabled Rule

I tried if-clauses, if-else-clauses, cascaded if-else-if-else-clauses etc. But I can’t get Tinderbox

####The current rule reads:

if($Check_A){$Check_B=false};

if($Check_B){$Check_A=false};

Ideas?

2

The problem is that if $Check_A is checked, and you check $Check_B, the rule runs and immediately sets $Check_B to false (because $Check_A is true).

You can’t approach this by testing only one attribute at a time. Your rule has to figure out what to do when both $Check_A and $Check_B are true. Which one to unselect? You’ll need to track the last value checked in a separate attribute. The following rule will do what you want, assuming you have defined a String attribute named “LastChecked”:

if ($Check_A & $Check_B) {
    if ($LastChecked == "Check_B") {
        $Check_B=false;
        $LastChecked="Check_A";
   } 
   else {
        $Check_A=false;
        $LastChecked="Check_B";
   }
}

The following document shows this in action, and behaves as you desire:

Check it out.tbx (53.4 KB)

You’ll have to do a bit of generalizing if you want to use this approach with more than three check boxes without going crazy.

3

Great, @galen! It works fine.

And I understand the needed hack of $LastChecked.

Wouldn’t you think, too, Galen, @eastgate, @mwra, that having:

  • some sort of radio-button-function in tinderbox would be rather handy?
  • Or maybe at least an if_else-command?

Or is there something like that hidden somewhere already? Otherwise, Galen seems to have a point when he writes:

4

I’m not sure. I presume this would be used in a KeyAttributes table, although entries there are one line high. That means the radio button (value) options would need to be listed on the same line limiting the visual utility of such a feature.

If you want a note to be in $CheckState ‘A’ or ‘B’ you could make a user String attribute and set it’s preferred values to “A;B”. the latter pre-populated the value pop-up. Now set $CheckState as a KA and use it’s pop-up to set the value (so no tying input errors). As the String attribute takes only one value, a note with a $CheckState value of ‘A’ if set to ‘B’ will replace the ‘A’ value. If there must be a default, perhaps ‘A’, then you set the attribute’s default value to A.

This begs the question of whether the radio button is just Ui dressing or has a further, as yet unrevealed, purpose?

2 Likes
5

I don’t see what a radio button would offer that a boolean attribute does not. And what would the radio button be, anyway? They have to come in pairs, or more, per Apple guidelines

A radio button displays the setting of something in your application and is part of a group in which only one button can be on at a time. Use a group of radio buttons to choose among several options which are mutually exclusive.

So where would this button set appear? In key attributes? Maps? I would imagine there would be extensive rebuilding needed down in Tinderbox’s basement to accommodate something that can, actually, be accommodated with sets of booleans already.

1 Like
6

Booleans would be painful for the reasons Galen stated, but Mark’s suggestion of a String attribute with pre-populated options ought to do the trick just fine. That’s all a radio button is, after all.