howard@cpocd2.UUCP (Howard A. Landman) (01/27/88)
Last night I was writing a small script to select random cards and speak the
messages on those cards. I wanted this to run forever until the mouse is
pressed. The first thing I tried was (approximately):
STACK SCRIPT
on OpenStack
visual dissolve slowly
global done
put empty into done
repeat
go to any card
...
until done is not empty
end OpenStack
on MouseUp
put true into done
end MouseUp
I got several surprises when I ran this. First, the dissolve only happened for
the first transition. After that, cards just appeared normally. Second, I
was thinking of mouse events as being interrupts, when in fact they are queued
up until you ask for events. The OpenStack handler doesn't do any event
processing. Thus the script was uninterruptible except by powering the
machine down.
However, it got me to thinking about global variables. If I understand HC
correctly, there are only two kinds of variables: local to a particular
handler, or global to all of HyperCard (even across different stacks). This
seems wrong given the modular (card, stack) nature of HC. Consider a not-too-
distant future when some poor user has hundreds of stacks containing tens of
thousands of cards. If two different stacks use the same name for a global
variable, they may affect each others' behavior! This is especially bad since
stacks may be duplicated, and buttons, fields, and cards may be copied from
one stack to another, greatly increasing the chance of duplicate global
variable names. Thus, variable names like "howardIsDone47XX" are not much
safer than variable names like "done" or "x".
What would be far better is having the ability to select the scope of a
variable to be one of:
this handler
this script
this card
this background
this stack
all stacks
and possibly even a few other possibilities. Only the first and last of these
is available now.
Any comments? I would propose keywords like StackGlobal, BkgdGlobal,
CardGlobal, etc. since they're easy to remember and consistent with each other.
A better convention is certainly possible, since in my scheme it's not clear
There are other scoping problems in HC, of course. As an example, I built a
There are other scoping problems in HC, of course. As an example, I built a
"Christmas Card List" stack for my wife. Each card needed to have 20 check
boxes, 2 per year (SENT and RCVD). I first tried to make these background
buttons, figuring that (by analogy with fields) the STATE of each button surely
had to be a property of each CARD, not of the BACKGROUND. Wrong. The only way
to get this to work was to paste 20 buttons on each card. So, the stack has
around 2000 card buttons, each with its own tiny script, which could have been
replaced by 20 background buttons if HC had been designed slightly differently.
Also, I had to tell her to *NEVER* use command-N in that stack, because the new
card wouldn't have any card buttons on it.
What is the advantage of having the state of a background check box be the
same on all cards? Was one bit per card of overhead too much to spend?
(Hint: the correct answer is *NO*!)
--
Howard A. Landman
{oliveb,hplabs}!intelca!mipos3!cpocd2!howard
howard%cpocd2.intel.com@RELAY.CS.NET
One hand clapping sounds a lot like two han