>This is already on the feature-request list. Implementation would
>even be relatively straightforward (no file format change required).
>But demand has been minimal, and we got stuck on the API. How would
>you set it to this third state? What happens when you get the hilite
>of a button in this state? Can any checkbox button be set to this
>state, or is a new style required?
>
>A few of other issues: What is the behavior when the user clicks on a
>button in this state? Can they re-select this state (maybe with a
>modifier-key click)? And what exactly should the button look like on
>the various platforms?
Well, SuperCard uses a separate property for radio buttons and checkboxes called the "mixedValue". When set to true, the button shows the "-", regardless of the status of its "hilite" property. Scripts in the button then determine what to do; i.e.:
on mouseUp
if the mixedValue of me is false then
-- check the hilite state to see what to do
if the hilite of me is true then
-- do "on" stuff
else
-- do "off" stuff
end if
else
-- do "mixed" stuff
end if
end mouseUp
Similarly, it is up to the developer as to what the behavior should be when the user clicks on the button. If the developer wants to cycle through the states, they would script it that way:
on mouseUp
-- Cycle through "on", "off", "mixed" states
if the mixedValue of me is false then
if the hilite of me is true then
set the hilite of me to false
else
set the mixedValue of me to true -- shows the "-"
end if
else
set the mixedValue of me to false -- hides the "-"
set the hilite of me to true
end if
end mouseUp
In some respects, this is a good way because it allows the developer the choice of how to handle the various states. It also doesn't have the potential for breaking all the scripts that say "if the hilite of me is true then..." because if the button had a third hilite state, it would have to be returned in some way that was (by definition) not a boolean value.
On the other hand, it means a lot of hand-coding. I don't see a better way to handle this; it can't really be handled "automatically" by MC because the third state is one which is contextual in nature - only the developer knows whether the button *should* show the third state, and therefore it should (IMHO) be left to him/her.
Perhaps the distinction should be drawn between showing the third state *initially*, and then managing the clicks on the buttons after that. For example, it might be useful to have a property for the button that *allows* it to have a third state, but doesn't necessarily show it when set (unlike the mixedValue in SC). If we were to call this the "allowMixedValues" (or equivalent) for the button and the "hilite" states for the object were not boolean, but string values of "true", "false" or "mixed", then the developer could set the the initial state of the button and then MC would handle the automatic cycling of the states for each time the user clicked on the button after that.
This would mean that the developer would not have to include the "set the mixedValue" statements in the mouseUp handler of the buttons (as shown above); in fact, the developer would need to add no "hilite-setting" code in the checkboxes at all (assuming the autoHilite property was true). When it came time to check the state of the button later (for example when clicking a standard button in the window), the button could easily check the state of the checkbox this way:
on mouseUp
switch (the hilite of btn "ThreeState Button")
case "true"
-- do true stuff
break
case "false"
-- do false stuff
break
case "mixed"
-- do mixed stuff
break
end switch
end mouseUp
Unfortunately, three states of hilite removes simple boolean statements like:
if (the hilite of btn "OK") then
or
if not(the hilite of btn "OK") then
etc.
Oh well, my $0.02. Any comments/suggestions?
Ken Ray
Sons of Thunder Software
