Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!umd5!zben
From: zben@umd5.umd.edu (Ben Cranston)
Newsgroups: comp.sys.mac
Subject: Re: EXACT screen refresh rate, and other items
Message-ID: <1719@umd5.umd.edu>
Date: Sat, 30-May-87 17:52:21 EDT
Article-I.D.: umd5.1719
Posted: Sat May 30 17:52:21 1987
Date-Received: Mon, 1-Jun-87 06:44:44 EDT
References: <71@wjh12.HARVARD.EDU>
Reply-To: zben@umd5.umd.edu.UUCP (Ben Cranston)
Organization: University of Maryland, College Park
Lines: 20
Summary: Why button only changes on "tick" boundaries

In article <71@wjh12.HARVARD.EDU> duc@wjh12.UUCP (Dan Costin) writes:

> ... In sum, how come Button() only returns a TRUE at tick boundaries?

The tick is probably used to debounce the button, otherwise you would
see many hundreds of buttonpresses each time the contacts break or make.

I was reading the Vertical Retrace Manager section of IM last night, and
I'm quite sure it said "button down for at least 4 ticks"...  If you want
more accuracy you could do the debouncing yourself.  Look at the hardware
button indicator.  When it changes state, wait awhile and check it again.
Don't accept a change till it settles down.  If your program has nothing
better to do you could use a timing loop, but perhaps each cycle of your
event loop would be fast enough to get reliable debouncing AND the better
than "tick" resolution you imply you require...
-- 
Copyright 1987 Ben Cranston (you may redistribute ONLY if your recipients can).
       umd5.UUCP    <=      {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
zben @ umd2.UMD.EDU         Kingdom of Merryland UniSys 1100/92
       umd2.BITNET          "via HASP with RSCS"