delaney@XN.LL.MIT.EDU (John R. Delaney) (03/29/89)
I would like to verify some Hypertalk semantics that I find odd (and inconvenient). When you close a stack (by going to another stack or whatever), is there an implicit "unlock screen" command? Does it occur before or after the associate "closeStack" message handlers are executed? Is there also an implicit "unlock screen" command when you open a stack? And when does it occur? I THINK there are such implicit commands and that they occur before the "closeStack" message handler execute and after the "openStack" message handlers. If so, I would like to argue for changing the timing to reverse the orders of the implicit "unlock screen" and message handler executions. If not, then I am having some very peculiar problem I will have to chase down. Why do I care? My stack in this case wants to alter which of N background radio buttons its highlighted as I go from card to card depending on a background field's contents on the displayed card. When I close a card, I turn off whatever radio button is on. When I open a card, I turn on the desired radio button. To make the transition visually smooth, I lock the screen before turning the one radio button off and unlock the screen after turning the other radio button on. It is straight-forward (if non-intuitive) to make transitions smooth when a new card is created (with a default radio button on) and when a card is deleted. But I cannot make the transition smooth when I open and close the stack; there is always a period when no button is highlighted as the stack is openned and as it is being closed. Why do I care about something so modest? I am a perfectionist. John
stone@hydra.unm.edu (Andrew Stone CS.DEPT) (03/29/89)
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 || ||<<++>>||<<-->>||<<==>>||<<++>>||<<??>>||<<++>>||<<-->>||<<==>>||<<++>>||
jtw@wuee1.wustl.edu (Trent Wohlschlaeger) (04/02/89)
In article <4737@charon.unm.edu> stone@hydra.unm.edu.UUCP (Andrew Stone CS.DEPT) writes: >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. I find this to be helpful in many instances, too. >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: > >[ a script to copy a button on a "New Card" message ] > >Hope this helps. andrew > The problem I have with this is that the overhead in size for several card buttons per card (including scripts) is much greater than the disk space for a single background field and the corresponding script in the opencard handler. For example, I wrote a stack for a friend of mine (which may or may not become commercial, so no disclosure yet) that has ~25 buttons whose highlite property is card dependent. Sure, it takes a (barely) noticable amount of time to set these highlites every time a card is opened, but when I converted to background buttons and a hidden field, I achieved about 70% stack size reduction. Now that the stack has grown to ~500 cards, this is significant. Setting lockscreen to true before you do the button highliting seems to speed the process up, somewhat. Although sometimes I like to watch the highlite states ripple through. I'm not really disagreeing with Andrew. If you have a small stack with a few cards and a few buttons per card, then this might be fine. If not, you might wake up one morning to find that your stack has swallowed up your hard drive. The changes are a lot easier and a lot faster to make when your stack is small. Sorry to have rambled, but I wanted to make sure I had enough "new" lines for this to get past the news poster. Trent