roy@alanine.phri.nyu.edu (Roy Smith) (12/21/90)
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?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane? Did you say arcane? It wouldn't be Unix if it wasn't arcane!"stevec@Apple.COM (Steve Christensen) (12/22/90)
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.
leonardr@svc.portal.com (Leonard Rosenthol) (12/24/90)
In article <47550@apple.Apple.COM>, stevec@Apple.COM (Steve Christensen) writes: > 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: > > [ Stuff from IM Removed] > > 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... > 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. Here is a 'StandardKeyFilter' which just handles the default button (1) and the Cancel Button (2). FUNCTION StandardKeyFilter(theDialog: DialogPeek; VAR theEvent: EventRecord; VAR itemHit: INTEGER): BOOLEAN; VAR key: CHAR; BEGIN StandardKeyFilter := FALSE; {init it!} IF (theEvent.what = keyDown) OR (theEvent.what = autoKey) THEN BEGIN key := Chr(BAND(theEvent.message, $FF)); CASE key OF cr, etx: BEGIN StandardKeyFilter := TRUE; itemHit := FlashItem(theDialog, 1); END; '.', '>', esc: BEGIN IF (BAnd(theEvent.modifiers, cmdKey) <> 0) THEN {CmdKey} BEGIN StandardKeyFilter := TRUE; itemHit := FlashItem(theDialog, 2); END; END; END; END; END; A couple of notes about the above routine: 1) FlashItem is a routine I used which flashes the button, as per the HIG, for visual feedback. The reason that it returns a value is that it also checks the cntrlHilite of the button to see it is enabled, and if not then returns 0 instead of the ID. 2) The handling of cmd-. is not handled extremely well WRT foreign OS and keyboards since it assumes that the > is a shifted . 3) It's in Pascal - conversion to C is an exercise to the reader ;-) -- ---------------------------------------------------------------------- + Leonard Rosenthol | Internet: leonardr@sv.portal.com + + Software Ventures | GEnie: MACgician + + MicroPhone II Development Team | AOL: MACgician1 + ----------------------------------------------------------------------
stevec@Apple.COM (Steve Christensen) (01/03/91)
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.