home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!elroy.jpl.nasa.gov!decwrl!concert!samba!usenet
- From: Bathsheba.Grossman@launchpad.unc.edu (Bathsheba Grossman)
- Subject: Re: Spurious invalidation
- Message-ID: <1992Nov7.221521.21889@samba.oit.unc.edu>
- Sender: usenet@samba.oit.unc.edu
- Nntp-Posting-Host: lambada.oit.unc.edu
- Organization: University of North Carolina Extended Bulletin Board Service
- References: <1992Nov6.170232.21241@alw.nih.gov> <absurd-061192133636@seuss.apple.com> <1992Nov7.172136.7170@athena.mit.edu>
- Date: Sat, 7 Nov 1992 22:15:21 GMT
- Lines: 29
-
- >>(Chris Spiral Catfish Tate) wrote:
- >>> Problem: calling SetCTitle() (and possibly SetCtlValue()) on controls in the
- >>> dialog is forcing an update. This is pretty bad in my case, since redrawing
- >>> the dialog is rather time-consuming.
-
- >>stick a little code at the beginning of your user item drawing procedure
- >>that makes sure that your user item intersects the union of the visRgn and
- >>the clipRgn; this way you can be sure that your user item actually
- >>needs to be redrawn before undertaking the task.
-
- >>Tim Dierks
- >The region to check is the Intersection (SectRgn) (I-184) of the visRgn
- >& clipRgn. The UnionRgn would (under most cases) not avoid any drawing.
-
- You don't have to do this SectRgn if you're using BeginUpdate/EndUpdate
- because BeginUpdate does it for you and puts the result in the visRgn,
- then EndUpdate puts it back to normal.
- Also, using UpdtDialog (IV-60) or UpdtControl (IV-53) instead of
- DrawDialog/DrawControls might just solve the whole problem. (There, you
- knew IV was good for something.)
-
- -Sheba
-
-
- --
- The opinions expressed are not necessarily those of the University of
- North Carolina at Chapel Hill, the Campus Office for Information
- Technology, or the Experimental Bulletin Board Service.
- internet: laUNChpad.unc.edu or 152.2.22.80
-