39clocks@violet.berkeley.edu.UUCP (09/27/87)
After reading the truly lucid description of the concept of messages or
"HyperTalk" in the HyperCard Script Language Guide, I thought I understood what
was going on well enough to try to implement pulldown menus in HyperCard. I
started by drawing a menubar below Apple's menubar, typed in a few menuNames,
put invisible buttons over them and then created the dropdown portions of the
menus with shadowed buttons. I created a script for the first menuName button
that would show the buttons below it on a mouseDown and make them invisible
on a mouseUp. In the same script is a message handler for mousestilldown
which keeps track of the vertical position of the cursor in such a way that
the menuitems are hilited when the cursor passes over them.
This all works quite well, although it is a little bit slow, however there
is one major problem: A menu is supposed to work by executing an action based
upon which menuItem was hilited when the mouse was released. I can't get this
to work, in fact, I cannot figure out what happens to the mouseUp message that
is supposed to be sent when the mouse is released.
The hierarchy of message passing in HyperCard is supposed to be from a
button or field > card > background > stack > home stack > HyperCard. So
to try to figure out where the mouseUp message was going to I placed mouseUp
handlers that put things like "card got it" into the message window into all
of the objects except the last two. I was a little disapointed when I
then clicked the mouse in a button, held the button down while moving the mouse
out of the button and then upon releasing the mouse found that none of the
objects received a mouseUp message. It seems that an object will only
recognize a mouseUp message if the mouseDown occured in in that object. Drag:(.
Has anyone else out there had similar experiences or figured a way to
implement pulldown menus?
For the record, I think that the HyperCard Script Language Guide that apda
is selling is just that, _A GUIDE_. It is definitely _not_ a reference which
what I was expecting. But for $19.95 plus $6.00 for shipping what can you
expect. A little more than the 3/8" document and diskette that you receive
which seems to have some errors. Take the example given for for MouseV on
page 10-7, mine reads:
if mouseV > 342 put "Stop" into msg
that's funny, to get this to work on my version of HyperCard I have to type:
if mouseV() > 342 then put "Stop" into msg or alternatively:
if the mouseV > 342 then put "Stop" into msg
There also does not seem to be any elaboration on what parameters are
possible for "set cursor" and "set dragspeed". If you experiment you can
find out that set cursor accepts the parameters "1","2","3" and "4", but
this is really something that should be in the documentation.
Enough complaining... the document does warn that it is preliminary, does
not include final editorial corrections, final art work, an index or glossary
and may not include final technical changes. That's for sure.
Peter Marinac olson@endor.harvard.edu (Eric Olson) (09/28/87)
In article <5236@jade.BERKELEY.EDU> 39clocks@violet.berkeley.edu (Peter Marinac) writes: > > This all works quite well, although it is a little bit slow, however there >is one major problem: A menu is supposed to work by executing an action based >upon which menuItem was hilited when the mouse was released. I can't get this >to work, in fact, I cannot figure out what happens to the mouseUp message that >is supposed to be sent when the mouse is released. I do not talk hyper (yet), but, in normal :-) Mac programming, there is a global event mask, which normally filters out mouseup events. If there is a similar concept in Hypercard, you need to set the mask to all ones (in binary). -Eric Eric K. Olson olson@endor.harvard.edu harvard!endor!olson
pem@cadnetix.UUCP (Paul Meyer) (09/28/87)
In article <5236@jade.BERKELEY.EDU> 39clocks@violet.berkeley.edu (Peter Marinac) writes: >started by drawing a menubar below Apple's menubar, typed in a few menuNames, >put invisible buttons over them and then created the dropdown portions of the >menus with shadowed buttons. I created a script for the first menuName button >that would show the buttons below it on a mouseDown and make them invisible >on a mouseUp. In the same script is a message handler for mousestilldown >which keeps track of the vertical position of the cursor in such a way that >the menuitems are hilited when the cursor passes over them. ... > ...in fact, I cannot figure out what happens to the mouseUp message that >is supposed to be sent when the mouse is released. You missed an important point about the mouseup message. In order for buttons to work right, this must be (and is) true: MOUSEUP IS ONLY SENT IF THE CURSOR IS STILL INSIDE THE BUTTON WHEN THE BUTTON IS RELEASED. If this were not true, you could click inside a button and drag out of it and the button would still do its thing. Try this on a standard button. Try it on a standard go-away box. (etc.) The simple fact is, buttons are not menus- they are buttons. In a slightly less RTFM vein, you could do something like this: (in button script) on mousedown global themenu put the target into themenu (display the menu) end on stilldown global theitem (figure out which item you're on) (put some identifier for the item into theitem, including an identifier that means "out of menu boundary") end stilldown on mouseup global themenu put zero into themenu end mouseup on domymenu global theitem (dispatch on theitem) end domymenu on idle end idle (in card/bkgd script) on idle global themenu if themenu <> zero then send domymenu to themenu put zero into themenu end if end idle Of course, you could do all the dispatching from the higher level script, rather than sending "domymenu" to the button... In any case, this will do the right things--including doing nothing when the button is released in the menu header (the mouseup handler). Note that idles are sent at the same time as stilldowns, so you need to swallow them in the button script. I typed this code in off the cuff, so it might not work verbatim, but it should be close. -- pem@cadnetix.UUCP (nbires!isis!ico!cadnetix!pem)