Hi.
Klaus has given you a method. This gives the user a physical label.
Another way, and I think of this as a more "natural" method, is to set the "menuHistory" of the button. This actually "selects" the line that contains that data. This, to me, is far more robust for several reasons.
Try this. On a blank card. make an option button, It will be pre-loaded with three lines, "choice 1, choice 2 and choice3". Now make another ordinary button, and put this into its script:
Code: Select all
on mouseUp
set the label of btn 1 to any item of "choice 1,choice 2,choice 3"
answer the menuhistory of btn 1
end mouseUp
Now manually select line 3 ("choice 3") of the option button. This actually selects that third line, and shows "choice 3", which is the contents of the third line.
Now click on the ordinary button. You will see, after several tries, that the "label" of the option menu changes, but that the menuHistory never does. This is because we never "selected" a different line, we only changed the label of the button. Why does this matter? Well, two different properties are at play here, but only one works the option menu functionality directly. If you really start to use that option menu, where you select a line and then use a "menuPick" handler to do real work, or if you want the "label" of the button to reflect the actual line selected (and shown) in that button, then you have to deal with those properties. Remember, the label property "floats" above the actual selected line and trumps the display of the contents of that line. I do not see a case where the label should be set with such an object at all, if you ever want to use it for anything useful. But in that case, you do not need an option menu. Any button will do, as the label property is ubiquitous.
Is this clear? Do experiment for a bit until you understand the distinction.
Klaus, would you not agree?
Craig
