Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ucdavis!iris!lim
From: lim@iris.ucdavis.edu (Lloyd Lim)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Death of jGNEFilter?
Message-ID: <6040@ucdavis.ucdavis.edu>
Date: 27 Nov 89 09:43:47 GMT
References: <2323@hudson.acc.virginia.edu> <9068@hoptoad.uucp> <6020@ucdavis.ucdavis.edu> <9074@hoptoad.uucp> <2397@draken.nada.kth.se> <9085@hoptoad.uucp>
Sender: uucp@ucdavis.ucdavis.edu
Reply-To: lim@iris.ucdavis.edu (Lloyd Lim)
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science
Lines: 40

In article <9085@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <6020@ucdavis.ucdavis.edu> lim@iris.ucdavis.edu (Lloyd Lim) writes:
>>The best suggestion I can make is that you can head patch PostEvent and
>>PPostEvent if your patch doesn't move memory.  If you're doing something else
>>that doesn't move memory this might work for you.
>
>[...]
>
>However, now look at the problems with the GetNextEvent patch.  You
>will play the sound on the next GetNextEvent from anyone, which may not
>be the frontmost application -- and you still have the problem of not
>matching the events pulled off the queue by GetNextEvent to the sound
>desired.  This could be a problem with multiple events pending; suppose
>that, while a spreadsheet is being recalculated, the user gives two
>menu key commands, each of which has a different sound, and the first
>menu key command causes an activate event to happen, or brings up a
>modal dialog.  Even assuming you queue what you get from PostEvent and
>pull your stored events off the queue in order, one per GetNextEvent or
>WaitNextEvent, this situation will result in the second sound being
>played at an inappropriate time; either before the activate, or during
>the modal dialog.

It depends on what model you are trying to achieve.  If you want the
appropriate sound to occur when the character is being drawn on the screen (or
otherwise processed), then my solution will be bad in some cases.

However, if you want to emulate the hardware clicking that some terminals do
then this should work ok.  In this case the sound should occur soon after the
key was pressed and in the order the keys were pressed - not in the order the
program processes them.  It's not uncommon to press a terminal key, hear a
click as feedback, and then wait for a couple of seconds for the character to
appear when the system is overloaded.

I guess it depends which model the author wants to emulate.  I think arguments
could be made for both.

+++
Lloyd Lim     Internet: lim@iris.ucdavis.edu (128.120.57.20)
              Compuserve: 72647,660
              US Mail: 146 Lysle Leach Hall, U.C. Davis, Davis, CA 95616