Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!charon!hydra.unm.edu!stone
From: stone@hydra.unm.edu (Andrew Stone CS.DEPT)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: openStack & closeStack side effects
Keywords: side effects, timing
Message-ID: <4737@charon.unm.edu>
Date: 29 Mar 89 14:21:05 GMT
References: <1333@xn.LL.MIT.EDU>
Sender: root@charon.unm.edu
Reply-To: stone@hydra.unm.edu.UUCP (Andrew Stone CS.DEPT)
Organization: University of New Mexico, Albuquerque, NM
Lines: 38

In article <1333@xn.LL.MIT.EDU> delaney@XN.LL.MIT.EDU (John R. Delaney) writes:
>I would like to verify some Hypertalk semantics that I find odd (and
>inconvenient).
>
[Storing and restoring radio buttons with local values]

I usually use the set lockmessages to true and set lockmessages to false
pair to wrap code that is just supposed to do what I tell it.

As far as the radio button is concerned, instead of forever manipulating
the states to agree with another field, perhaps hidden, on that card, you
could try this tact:
Create a new Card level radio button when making a new card, this will then
always have the correct state connected with it:

on domenu which
  if which is "new card" then
    if the bg of this card is "theonewithradiostates" then
      lock screen
      choose button tool
      click at the loc of card button "theradiobutton"
      domenu "Copy Button"
      send "domenu new card" to hypercard
      domenu "Paste Button"
      ----set the hilite of button "theradiobutton" to initialState
      ----repeat here if there are more
      choose browse tool
      unlock screen
    else pass domenu
  else pass domenu
end domenu

Hope this helps.             andrew

||<<++>>||<<-->>||<<==>>||<<++>>||<<??>>||<<++>>||<<-->>||<<==>>||<<++>>||
||	   Andrew Stone	            ??		  Able was I            ||
||         stone@hydra.unm.edu	    <> 	    	ere I saw Elba          ||
||<<++>>||<<-->>||<<==>>||<<++>>||<<??>>||<<++>>||<<-->>||<<==>>||<<++>>||