Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!bu-cs!dartvax!eleazar.dartmouth.edu!matthews From: matthews@eleazar.dartmouth.edu (Jim Matthews) Newsgroups: comp.sys.mac.programmer Subject: Re: Saving area under dialog boxes (Re: WingZ) Message-ID: <13295@dartvax.Dartmouth.EDU> Date: 1 May 89 15:48:31 GMT References: <598@eutrc3.UUCP> <1774@ccnysci.UUCP> <29827@apple.Apple.COM> Sender: news@dartvax.Dartmouth.EDU Reply-To: matthews@eleazar.dartmouth.edu (Jim Matthews) Organization: Dartmouth College, Hanover, NH Lines: 27 In article <29827@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: >In article davidl@intelob.intel.com (David Levine) writes: >>But the original poster seems to have been talking about the >>application copying the affected area of ITS OWN WINDOW to a buffer >>and then restoring ITS OWN WINDOW. What could be wrong with that? >> > >Saving data from your own window into an offscreen buffer is not much of a >problem _right now_. It should even work in the forseeable future. There's (at least) one way in which it doesn't work right now. I have a program that saves the bits of a text-editing window as part of a scheme for doing menus in windows. I only save a 1-bit deep BitMap, since I use old-style GrafPorts. But some of my users have the Kolor cdev set up to make their text selection some presumably gaudy color. When I restore the bits of the selected text the color information is lost, and my users are upset. I don't know whether to blame myself or the architects of Color QuickDraw, but this is one way in which CQD is *not* backwards compatible. I understand that I can keep Kolor from putting color pixels in my grafports somehow, but so far I haven't figured out how. After all, this bug is my only leverage for getting a color monitor :-). Jim Matthews Dartmouth Software Development