chuq%plaid@Sun.COM (Chuq Von Rospach) (10/07/87)
You folks are two for two so far, so I thought I'd toss another one at you
(by the way, thanks!). This one is radio buttons.
I can't find a stack that uses radio buttons. As far as I can tell, there is
no documentation on using them in either Goodman's book or the help stack
(should I take this as a hint? I NEED radio buttons). Goodman simply says
"you need a big script to handle radio buttons" which is stating the obvious
without telling me anything.
I know what I need to do to handle a set of radio buttons properly. What I
don't know, and can't find any documentation on, is (1) how to query the
state of a radio button ("hi, are you checked?") and how to alter it ("hey,
turn yourself on!"). Anyone know the magic incantation?
chuq
Chuq Von Rospach chuq@sun.COM
Editor, OtherRealms Delphi: CHUQ
Bye bye life! Bye bye happiness! Hello, loneliness, I think I'm gonna die.beloin@batcomputer.tn.cornell.edu (Ron Beloin) (10/07/87)
In article <30200@sun.uucp> chuq%plaid@Sun.COM (Chuq Von Rospach) writes: > >I can't find a stack that uses radio buttons. As far as I can tell, there is >no documentation on using them in either Goodman's book or the help stack Just as other buttons, "the hilite of <button>" returns true or false. The home stack card for setting user levels uses radio buttons as a group. Ron Beloin, Ecosystems Research Center, Corson Hall, Cornell, Ithaca,NY 14853 >> opinions << BITNET:BELOIN@CRNLTHRY; INTERNET:beloin@tcgould.tn.cornell.edu >> are mine << UUCP:{cmcl2,shasta,uw-beaver,rochester}!cornell!tcgould!beloin
fry@huma1.HARVARD.EDU (David Fry) (10/07/87)
In article <30200@sun.uucp> chuq%plaid@Sun.COM (Chuq Von Rospach) writes: >I can't find a stack that uses radio buttons. As far as I can tell, there is >no documentation on using them in either Goodman's book or the help stack >(should I take this as a hint? I NEED radio buttons). Goodman simply says >"you need a big script to handle radio buttons" which is stating the obvious >without telling me anything. > >I know what I need to do to handle a set of radio buttons properly. What I >don't know, and can't find any documentation on, is (1) how to query the >state of a radio button ("hi, are you checked?") and how to alter it ("hey, >turn yourself on!"). Anyone know the magic incantation? Look at the phone message card in the Stack Ideas stack. Those check boxes on the right hand side might as well be radio buttons; the method used for the boxes will work just well for what you want to do. The basic idea is to make an invisible field which holds the word "true" or "false," or whatever you want it to say, which corresponds to a on or off state for the button. Then when the button is clicked have the script check the contents of the field, toggle the value, and highlight or unhighlight the button accordingly. David Fry fry@huma1.harvard.EDU Department of Mathematics fry@harvma1.bitnet Harvard University ...!harvard!huma1!fry Cambridge, MA 02138
sysop@stech.UUCP (Jan Harrington) (10/08/87)
in article <30200@sun.uucp>, chuq%plaid@Sun.COM (Chuq Von Rospach) says: > > I know what I need to do to handle a set of radio buttons properly. What I > don't know, and can't find any documentation on, is (1) how to query the > state of a radio button ("hi, are you checked?") and how to alter it ("hey, > turn yourself on!"). Anyone know the magic incantation? > How you handle the highlighting depends on whether you've checked Auto hilight when you defined the button. If Auto hilight is checked (in that dialog box you get for buttons), then Hypercard will take care of turning the button on and off. You can check the button's state with something like: if autoHilite of button ID XX is true then ..... Replace the XX, of course, with the right button ID or ID XX with the button's name if the script is attached to something other than the button itself. If the script is attached to the button itself, then you don't need the button identifier. If Auto hilight isn't selected, then you must attach a script to each button which detects mouseup events, checks the current hilite state, and then sets the button accordingly: if hilite is true then set hilite false else set hilite true ..... In most cases, using Auto hilite is certainly easier! Jan Harrington, sysop Scholastech Telecommunications ihnp4!husc6!amcad!stech!sysop
winkler@apple.UUCP (Dan Winkler) (10/08/87)
The user preferences card of the home stack shipped with 1.0.1 has an example of how to use radio buttons.
psych@watdcsu.UUCP (10/09/87)
In article <166@stech.UUCP> sysop@stech.UUCP (Jan Harrington) writes:
[
[If Auto hilight isn't selected, then you must attach a script to each button
[which detects mouseup events, checks the current hilite state, and then sets
[the button accordingly:
[
[ if hilite is true then
[ set hilite false
[ else
[ set hilite true
[ .....
A simpler script for doint the same thing is
set hilite of the target to not hilite of the target
This will cause the checks to flip on or off with every click. AutoHilite
doesn't quite work the same way and can't be used properly with radio buttons.
Richard Crispin
Dept. of Psychology
University of Waterloo
Waterloo, Ont.
Canada N2L 3G1
(519)885-1211 ext 2879faulkner@scdpyr.UUCP (Bill Faulkner) (10/12/87)
In article <166@stech.UUCP>, sysop@stech.UUCP (Jan Harrington) writes: > How you handle the highlighting depends on whether you've checked Auto hilight > when you defined the button. If Auto hilight is checked (in that dialog box > you get for buttons), then Hypercard will take care of turning the button on > and off. You can check the button's state with something like: > > if autoHilite of button ID XX is true then > ..... > > Replace the XX, of course, with the right button ID or ID XX with the button's > name if the script is attached to something other than the button itself. If > the script is attached to the button itself, then you don't need the button > identifier. What you said is true, however, you are misleading people. Both hilite and autoHilite are properties of a button, but they are vastly different. Checking the state of autoHilite, tells you nothing about the button being "on" > If Auto hilight isn't selected, then you must attach a script to each button > which detects mouseup events, checks the current hilite state, and then sets > the button accordingly: > > if hilite is true then > set hilite false > else > set hilite true > ..... > > In most cases, using Auto hilite is certainly easier! NO NO NO NO! You don't understand radio buttons at all! If you click on a hilited radio button it should remain on. And for radio buttons, Autohilite is NOT the way to proceede. I know, because I have developed a stack that uses radio buttons. Now to answer Chuq's question about how to develop radio buttons. First, create the set of buttons that you want to use as a set of radio buttons and organize them in a logical manner. Set the Autohilite to off and show name to on. Say you have five buttons numbered 1-5. The script for button number 1 would be like this: on mouseUp set hilite of button 2 to false set hilite of button 3 to false set hilite of button 4 to false set hilite of button 5 to false set hilite of button 1 to true -- -- do what ever this button is supposed to do -- end mouseUp The other 4 buttons would proceed in a similar fashion, with the script of button n that turns the hilite of button n to true and all the others to false. This will give you the action of standard "radio buttons". Also note, that due to personal prefence, I will set the hilite of button n to true after all the other button hilites are set to false. This is to prevent seeing 2 radio buttons checked at the same time, although this time is rather small. I would rather buttons hilited for the split second it takes to change all the button's states. True, it is not the most elegant solution to the problem, but it is what you are stuck with, since hypercard doesn't know about radio buttons other than they are just another button style. Bill -- Bill Faulkner * NCAR (Nat'l Center for Atmospheric Research) PO Box 3000 * Boulder, CO 80307-3000 * 303-497-1259 UUCP: faulkner@scdpyr.UUCP or ..!hao!scdpyr!faulkner INTERNET: faulkner@scdpyr.ucar.edu ARPA: faulkner%ncar@csnet-relay.arpa
darryl@ism780c.UUCP (Darryl Richman) (10/15/87)
In article <179@scdpyr.UUCP> faulkner@scdpyr.UUCP (Bill Faulkner) writes:
=NO NO NO NO! You don't understand radio buttons at all! If you click on
=a hilited radio button it should remain on. And for radio buttons,
=Autohilite is NOT the way to proceede. I know, because I have developed
=a stack that uses radio buttons.
Umm, can we keep the hysteria level down? Thanks.
=Now to answer Chuq's question about how to develop radio buttons.
=
=First, create the set of buttons that you want to use as a set of radio
=buttons and organize them in a logical manner. Set the Autohilite to off
=and show name to on.
So far, so good.
= Say you have five buttons numbered 1-5. The script
=for button number 1 would be like this:
=
=on mouseUp
= set hilite of button 2 to false
= set hilite of button 3 to false
= set hilite of button 4 to false
= set hilite of button 5 to false
= set hilite of button 1 to true
= --
= -- do what ever this button is supposed to do
= --
=end mouseUp
Now, rather than place this script in each button, where you'll have to
go back and modify each one when you add/delete another button, do it this
way:
1. Add a script, "on clearButtons" (or whatever), to the card or
background (as appropriate for your stack). clearButtons sets
the hilite of all of the buttons in the group to false. I have
a stack with several groups, so each has its own clearXxx handler.
2. In each button, create "on mouseUp" as follows:
on mouseUp
send clearButtons to this {card,background}
set hilite of me to true
end mouseUp
This same script can now be copied (pretzel C in the script editor) and
pasted (pretzel V) into each button, without changes.
--
Copyright (C) 1987 Darryl Richman INTERACTIVE Systems Corporation
The views expressed above are ...!cca!ima!ism780c!darryl
those of the author. ...!sdcrdcf!cca@pur-phy (Charles C. Allen) (10/18/87)
Well, I've yet to see the following method appear, so I'll toss it
out. It has the advantage of not having to loop through all the
buttons in a cluster at any point.
* Create a new background field (named "direction" here). This
should probably be hidden. It's just a place to store info.
* Create a new, named background radio button. Setting
autoHilite works well.
* Include the following in the button's script:
on mouseUp
setDirection the short name of me
end mouseUp
* Duplicate the button as many times as you need (don't forget
to rename the clones).
* In either the background script or the stack script, include
the following handlers:
on openCard
set hilite of bkgnd button field "direction" to true
end openCard
on closeCard
set hilite of bkgnd button field "direction" to false
end closeCard
on setDirection dir
set hilite of bkgnd button field "direction" to false
put dir into field "direction"
set hilite of bkgnd button dir to true
end setDirection
This avoids having to loop over the buttons in the cluster at any
point, and you can add a new button to the cluster by just cloning an
existing one.
It looks reasonable with radio buttons, but icon buttons flash when
chosen with this method. Handling icon buttons properly is left as an
exercise for the reader :-)
Charlie Allen cca@newton.physics.purdue.edu