Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!ark1!nems!mimsy!mojo!russotto
From: russotto@eng.umd.edu (Matthew T. Russotto)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Missing update events in SFGetFile (system 7.0)
Message-ID: <1990Aug20.143954.2276@eng.umd.edu>
Date: 20 Aug 90 14:39:54 GMT
References: <1990Aug15.121158.813@lth.se> <1990Aug19.110544.12102@dhw68k.cts.com>
Sender: news@eng.umd.edu (The News System)
Organization: College of Engineering, Maryversity of Uniland, College Park
Lines: 33

In article <1990Aug19.110544.12102@dhw68k.cts.com> thecloud@dhw68k.cts.com (Ken McLeod) writes:
>the default palette and draws a color picture. Here's the problem:
>under 7.0a9, the call to SetPalette/ActivatePalette *erases* my alert
>window to white...anything previously drawn in the window is gone.
>Here's where it happens:
> 
> if (theEvent->what == updateEvt) {
>   SetPort(theDialog);
>   if (gInColor)
>     RGBForeColor(&blackRGB);
>   FillRect(&theDialog->portRect, black);  /* paint it black... */
>   if (gInColor) {
>     ourPal = GetNewPalette(200);   /* my default 'pltt' resource */
>     SetPalette((WindowPtr) -1L, ourPal, TRUE); /* as per TN #211 */
>     ActivatePalette((WindowPtr) theDialog);
>   }
>   ...
>   /* When running under 6.0.x, the window is still black at this point.
>      Under 7.0a9, the window has been erased to white (not good!) */
>   DrawPicture(myClrPic, &tempRect);
> 
> Is this a known System 7 bug (I hope)?

Actually, it sounds like correct behavior.  It is perfectly reasonable for
the dialog to be erased when it is made invalid by the SetPalette call.  I
see two easy workarounds-- move the FillRect to AFTER the if statement, or
change the SetPalette to
SetPalette((WindowPtr) -1L, ourPal, FALSE);
(If you tell SetPalette to update on change of color environment, don't
complain too much when it does :-) )
--
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions?