Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!stevec
From: stevec@Apple.COM (Steve Christensen)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Question about dialog filter procs
Message-ID: <47691@apple.Apple.COM>
Date: 3 Jan 91 02:06:11 GMT
References: <1990Dec21.152707.108@phri.nyu.edu> <47550@apple.Apple.COM> <1990Dec23.221117.16800@svc.portal.com>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 30

leonardr@svc.portal.com (Leonard Rosenthol) writes:
>stevec@Apple.COM (Steve Christensen) writes:
>> roy@alanine.phri.nyu.edu (Roy Smith) asks:
>> >...why you have to check for Return and Enter in your own filterProc
>> >since doesn't the default filterProc then handle all the stuff yours
>> >passes up?
>> 
>> I believe that the filterProc you specify replaces the standard filterProc
>> which is why it asks you to do the additional key checking.  That way you
>> have complete control over how your dialog will behave...
>> 
>	My understanding has always been exactly the opposite, in that the
>filterProc that you supply is 'stacked' on top of the standard one.  If you 
>return FALSE for any event, then it goes to the standard filterProc for 
>processing, BUT you also have to remember to leave theEvent intact, since
>it just uses theEvent...This is also beneficial since you can modify the
>eventRecord, and then pass back FALSE to let the standard filter proc handle
>it.
> [sample filterProc code deleted]

I looked thru the ModalDialog code and if a filterProc is specified, it uses
it ELSE it uses the default one.  Not both...

steve

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen	|  Apple Computer, Inc.		|  Disclaimer:
			|  20525 Mariani Ave, MS-81CS	|   the above may be
  stevec@apple.com	|  Cupertino, CA  95014		|   a lie...or not.