[comp.sys.mac.hypercard] Apple Thought Police and doubleclicks

jk3t+@andrew.cmu.edu (Jonathan King) (09/14/90)

rmh@apple.com (Rick Holzgrafe) writes:
> In article <10164@goofy.Apple.COM> Griffiths.R@AppleLink.Apple.com (Rob 
> Griffiths) writes:
> >
> > [handler which checks for double clicks in an ungood way]
> >
> > Just attach this to the object you wish to check, and add the code to 
> > perform whatever actions you desire. One nice side benefit is that you 
> > can make a single click perform one action (for instance, display a 
> > menu), 
> > and a double click another (go directly to some card).
> 
> Just a friendly warning... the Apple Thought Police will getcha if you 
> break a basic rule about clicking: NEVER WAIT FOR THE SECOND CLICK. You 
> should do something immediately when you receive the first click, then 
> something in addition when you receive the second. 

This isn't the only thing the Apple Thought Police tell you about
double clicks.

> That way response to 
> every click can be as fast as possible. The handler above, on the other 
> hand, twiddles its thumbs while waiting for further orders from the user. 
> (I know that HyperCard is slow enough that the difference may not be so 
> noticable. But Macs are getting faster, and HC 2.0 is supposed to really 
> zip along. And nobody likes to wait!)
> 
> Instead, I'd suggest something like the following, placed in the script of 
> your stack. (Forgive any syntax errors, this is typed on the fly.)
> 
> function isDoubleClick
>   global lastClickTime, lastClickItem
>   put the ticks into TM
>   if TM - lastClickTime < 20 and the id of the target is lastClickItem then
>     return true
>   else
>     put TM into lastClickTime
>     put the id of the target into lastClickItem
>     return false
>   end if
> end isDoubleClick

Okay.  This seems to be in the spirit of the real double click, in
that you check to make sure that the second click falls on the same
item as the first, but if you want to be *really* picky, you shouldn't
check for an arbitrary number of ticks separating the two clicks.
Instead, you should use the value of the toolbox function GetDblTime,
which is the suggested maximum number of ticks between the two clicks
of a double click, and which can be set by the user in the control
panel.  Truly good thought would thus require you to write the trivial
XFCN that returns GetDblTime, maybe put it in a global, and use *that*
for your comparison.

> Then do something like this in the script of each double-clickable item:

Or possibly better yet:  put something like the handler that follows
in *one* place along the static path, and use the value of 'the
target' to dispatch the appropriate message.  It's double ugly to
have, say, 20 identical mouseUp handlers scattered throughout your
stack when one can do the job.  I won't tell you about the chess stack
I wrote that at one time had 64 identical bg button scripts...the horror.

> on mouseup
>   if isDoubleClick then
>     -- do double-click stuff
>   else
>     -- do single-click stuff
>   end if
> end mouseUp

May the ATP purify your soul--that's not a double click you're
testing for!  

As we read from page 37 of Volume 1 of Inside Macintosh:

   If the downstroke of the second click follows the upstroke of the
   first by a short amount of time (as set by the user in the Control
   Panel), and if the locations of the two clicks are reasonably close
   together, the two clicks constitute a double-click.

So testing for the second click of a double click should be done in a
*mouseDown* handler.  This is actually really convenient, since it
allows you to separate the stuff you do with a single click
from a double click, and makes your mouseUp handler cleaner and
faster.  You should just stash the time when the last double click
ocurred in a global variable like 'lastDoubleTime' so your mouseUp
handler can decide whether the current mouseUp is must part of the
last double click or a "new" single click.

> Now, don't flame me about any of this - I don't work for the ATP. I just 
> don't like seeing people dragged screaming from their beds in the middle 
> of the night. :-) :-) :-)

And now for a brief meta-comment.  Apple has put out a brief Human
Interface Note (available for anonymous FTP from apple.apple.com) that
suggests you try to keep the Hypercard metaphor and the desktop
metaphor seperate, particularly when it comes to icon buttons in HC,
which often are meant to act differently from the icons in (say) the
Finder.  This is sometimes a good thing to keep in mind, not only
because it might help out the user but also because it might obviate
the need to go through all this mess to process double clicks in the
officaily sanctioned way.  But with the coming of more powerful
versions of Hypercard, the differences between stacks and other "real"
applications may begin to vanish.

> ==========================================================================
> Rick Holzgrafe              |    {sun,voder,nsc,mtxinu,dual}!apple!rmh
> Software Engineer           | AppleLink HOLZGRAFE1          rmh@apple.com
> Apple Computer, Inc.        |  "All opinions expressed are mine, and do
> 20525 Mariani Ave. MS: 3-PK |    not necessarily represent those of my
> Cupertino, CA 95014         |        employer, Apple Computer Inc."

jking