Path: utzoo!mnetor!tmsoft!torsqnt!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: <47550@apple.Apple.COM>
Date: 21 Dec 90 23:31:09 GMT
References: <1990Dec21.152707.108@phri.nyu.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 29

roy@alanine.phri.nyu.edu (Roy Smith) writes:
>	I don't fully grok what IM-I (page 416) says about using a
>filterProc with ModalDialog().  It says:
>
>	A function result of FALSE tells ModalDialog to go ahead
>	and handle the event ... NOTE: If you want it to be
>	consistent with the standard filterProc function, your
>	function should at least check whether the Return key or
>	Enter key was pressed and, if so, return 1 in itemHit and
>	a function result of TRUE.
>
>	What I don't understand is why you have to check for Return or Enter
>yourself and special case them.  If you do nothing at all with keyDown
>events and just return FALSE when you get one, with the event unchanged,
>won't the default filterProc then do what it usually does?  I guess what I'm
>really asking is if your filterProc is just stacked on top of the default
>one, or if it replaces it completely?

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...

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.