Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Getting usrItem to draw itself during ModalDialog
Message-ID: <6899@hoptoad.uucp>
Date: 7 Apr 89 00:18:10 GMT
References: <2580@tank.uchicago.edu> <11235@well.UUCP>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Distribution: na
Organization: Eclectic Software, San Francisco
Lines: 39

In article <2580@tank.uchicago.edu>, ra_robert@gsbacd.uchicago.edu writes:
> I'm having a problem getting a usrItem in a dialog to be drawn.  ...  To
> summarize, I generate (or try to generate) an update event from my
> modalDialog's filter by invaling my usrItem's rect...

In article <11235@well.UUCP> brecher@well.UUCP (Steve Brecher) writes:
>InvalRect operates on the current grafPort.  There is no assurance that
>your dialogUs port is current when your filter is called.  Use SetPort
>before calling InvalRect.

True as far as it goes, but there shouldn't even be a need to call
InvalRect.  I've used userItems for years and there's never been any
reason to call InvalRect on the item rectangle, except when the
contents have changed and need to be redrawn (and usually not then; you
can just do a direct redraw, or let utility software like the List
Manager do the direct redrawing).  Your dialog comes up with its whole
portRect invalidated; any user item procedure you have defined BEFORE
the dialog comes up (and bound to user items) will be called
automagically.

I think Robert's real problem is more likely to be that the user item
drawing procedure isn't getting bound to the item before the Dialog
Manager fields the first update event.  Maybe it's not getting bound at
all, or maybe he's binding it at a strange place (like right after
calling DrawDialog).  In my opinion, the proper way to do this is
generally to: GetNewDialog with dialog invisible, call
GetDItem/SetDItem to bind the procedure, call ShowWindow on the dialog,
and the handle the dialog normally (in Robert's case, with a call to
ModalDialog).  There is no need to muck about with filter procedures
with user items, though they are often useful with keyboard events and
sometimes with mouse events.

There is also the possibility that he has bound everything correctly,
but the userItem drawing procedure is incorrect, and so it seems not to
be called even though it is.  This should be easy enough to trap with a
debugger if so.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
"This signature is not to be quoted." -- Erland Sommarskog