Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!clyde.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!portal!sv!news
From: leonardr@svc.portal.com (Leonard Rosenthol)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Question about dialog filter procs
Message-ID: <1990Dec23.221117.16800@svc.portal.com>
Date: 23 Dec 90 22:11:17 GMT
References: <1990Dec21.152707.108@phri.nyu.edu> <47550@apple.Apple.COM>
Sender: news@svc.portal.com
Reply-To: leonardr@svc.portal.com (Leonard Rosenthol)
Organization: Software Ventures Corporation.
Lines: 72

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