From: potts@itl.itd.umich.edu (Paul Potts)
Subject: Re: Color Icons
Keywords: coloricon
Organization: Instructional Technology Laboratory, University of Michigan
Date: Thu, 27 Aug 1992 15:43:37 GMT

In article <1992Aug26.233800.21347@sagpd1> bberqu@sagpd1 () writes:
... stuff on color icons left out...
>
>Programmers question:
>
>I'm trying to use ModalDialog with a filterProc function which will
>handle popupmenus,  when I call ModalDialog and just let it sit there
>no mouse movement or anything, after a while, I get, I believe a system
>error #26 according to MacsBug, all my filter proc function does is 
>return (TRUE), I've also tried FALSE.  My impression from IM is that
>ModalDialog sits there and waits for a mousedown event within the dialog
>and when it gets either a itemhit or incontent or whatever, it then calls 
>the filterProc function (if defined), is this true? 

Not quite. When you set up a filter procedure, ModalDialog 
sends all the events to it for screening before it looks at them. 
This includes idle events, if there are any: you can actually do things
on idle time in your filter procedure, if you don't need any guarantee that
you will get idle time (you wont' get it in a very busy system, at least
not consistently).

ModalDialog *always* quits when it gets one of its triggering events,
like a keypress that it understands (return for the default button, for
example), or a mouse click in a button or on a checkbox. If you have, say,
ten check boxes and an OK button, and you want to keep the modal dialog up
until the OK button is hit, you have to call ModalDialog in a loop which
checks to see what was hit and only stops calling it if the OK button was
hit.

If you install a filter procedure, you return TRUE if you want ModalDialog
to quit. You have the event that got passed to your filter proc, so you
can change it if you want. You have a pointer to the item ID that ModalDialog
should return. Here's a diagram:

Without a filter proc (actually with the default filter proc)

---> event--->   ModalDialog  ---------> exit (return the item that was hit
                 Was a triggering              to dismiss the dialog)
                 event received?
                 

With a filter proc

---> event---> FilterProc ----> ModalDialog ----> exit (return the item that
               look at the       Did filterProc         was hit to dismiss the
               event; return     send "True?"           dialog)
               TRUE to tell      If so, dismiss
               ModalDialog that  the dialog.
               this was a        Otherwise, handle
             "triggering event", the event.
               otherwise return  
               false. 

No doubt someone will have a correction or two to add to the above, but
it should give you the general idea.

Here's an example: if you want your filter procedure to do something
on its own when the dialog is passed an update event, code it like this:

(fragment from a filter procedure)

switch (theEvent->what)
{
	case (updateEvt):
	HandleUpdate(theDialog);
	return FALSE;
/*Do not return an item hit value.  Returning
FALSE tells modalDialog to handle the update
event.  We have just added our own handling
of the event. */
	break;	

where "HandleUpdate" is a routine of mine that draws on the dialog.
Note that if your filter proc handles the event fully, and you don't want
ModalDialog to even see it, you can clear the event, although this generally
shouldn't be necessary since ModalDialog has useful default reactions to
most events.

>I assume that it 
>passes the dialog poointer/event record pointer/itemhit pointer, is this 
>true?  It looks like its calling my filterProc constantly, if this is true 
>do I need handle events within the filterProc?  Assuming all my parameters
>are correct for filterProc are correct, what am I doing wrong?

It is calling your filterProc constantly: every event goes through it. 

>
>An explanation of how ModalDialog and the filterProc functions work with
>each other would be nice.
>
>Thanks in advance

I hope this helps some with your understanding of modal dialogs. I'm not
sure how you should go about supporting a pop-up menu, but I tend to think
that doing all the mouse tracking in the filter proc is the wrong approach.
I was under the impression that there was pop-up support in the OS now.
Can anyone confirm or deny? If not you may want to build a window and
handle your own events from scratch, track the control, etc.

>
>Brian


-- 
"It'sVerySad / toSeeTheAncientAndDistinguishedGameThatUsedToBe / aModelOf
DecorumAndTranquilityBecomeLikeAnyOtherSportABattlegroundForRivalIdeologies
toSlugItOutWithGlee." (from _Chess_). -potts@itl.itd.umich.edu-
Newsgroups: comp.sys.mac.programmer