home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!nih-csl.dcrt.nih.gov!FAXCSL!FIXER
- From: fixer@faxcsl.dcrt.nih.gov (Chris Spiral Catfish Tate)
- Subject: Re: Spurious invalidation
- Message-ID: <1992Nov10.155449.14655@alw.nih.gov>
- Sender: postman@alw.nih.gov (AMDS Postmaster)
- Reply-To: fixer@faxcsl.dcrt.nih.gov
- Organization: Computer Systems Laboratory, DCRT, NIH
- References: <1992Nov6.170232.21241@alw.nih.gov> <absurd-061192133636@seuss.apple.com> <1992Nov7.172136.7170@athena.mit.edu>,<1992Nov7.221521.21889@samba.oit.unc.edu>
- Date: Tue, 10 Nov 1992 15:54:49 GMT
- Lines: 23
-
- Thanks to everyone who responded, either on the net or via email.
-
- In summary, what's happening is that indeed, SetCTitle() is *both* redrawing
- the control with its new title *and* causing an update event in the dialog.
- I'm not quite clear on why it has to generate the update event, but that's
- beside the point.
-
- The update event is causing all userItem procedures installed for the dialog
- to be called, whether or not they actually intersect the updateRgn established
- by the invalidation of the control's bounding rectangle. Checking to see
- whether each userItem actually *needs* to be redrawn prevents having to wade
- through all that (slow, DrawString) drawing unnecessarily.
-
- If you're absolutely sure you don't have to update anything else when the
- control changes its title, you can also call ValidRect() on its rectangle
- immediately following the call to SetCTitle(), and the update will be
- "cancelled."
-
- ------------------------------------------------------------------------------
- Christopher Tate | The Leadfoot Collection, Continued:
- Management System Designers | * Red Barchetta (Rush)
- | * Old Time Rock And Roll (Bob Seeger)
- fixer@faxcsl.dcrt.nih.gov | Because driving fast is a cathartic experience.
-