home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sdd.hp.com!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!haven.umd.edu!decuac!pa.dec.com!decwrl!apple!mumbo.apple.com!gallant.apple.com!seuss.apple.com!user
- From: absurd@apple.apple.com (Tim Dierks, software saboteur)
- Subject: Re: Spurious invalidation
- Sender: news@gallant.apple.com
- Message-ID: <absurd-061192133636@seuss.apple.com>
- Date: Fri, 6 Nov 1992 22:42:36 GMT
- References: <1992Nov6.170232.21241@alw.nih.gov>
- Organization: MacDTS Marauders
- Followup-To: comp.sys.mac.programmer
- Lines: 21
-
- In article <1992Nov6.170232.21241@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov
- (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.
- >
- > Does anyone have any idea what's happening, and how I might go about preventing
- > it? Calling ValidRect() on the slow-to-draw userItem's rectangle after the
- > call to SetCTitle() doesn't seem to solve the problem; it's still updated.
-
- Sure enough, controls will invalidate themselves (or the control manager
- does it; I can't remember). This isn't the real problem; the problem is
- that your user items are being drawn when they don't need to be. I would
- 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. (For extra points,
- only redraw the bits that need to be redrawn.)
-
- Tim Dierks
- MacDTS, why not?
-