sund@tde.lth.se (Lars Sundstr|m) (08/15/90)
When using SFPGetFile in system 7.0 it seems like no update event appears when the dialog shows up. Should it be like this or not? If so, it will not be possible to draw the outline of the default button upon an update event - not without creating another userItem. I checked the Bug Stack but couldn't find anything. Lars Sundstroem
thecloud@dhw68k.cts.com (Ken McLeod) (08/19/90)
In article <1990Aug15.121158.813@lth.se> sund@tde.lth.se (Lars Sundstr|m) writes: >When using SFPGetFile in system 7.0 it seems like no update event >appears when the dialog shows up. Should it be like this or not? >If so, it will not be possible to draw the outline of the default >button upon an update event - not without creating another userItem. >I checked the Bug Stack but couldn't find anything. ^^^^^^^^^ Is there a "System 7.0 Bug Stack" out there? Is this official stuff? I thought they weren't counting the bugs yet :-) If this is a topic open for discussion, let me describe something I've noticed in 7.0a9 which may be old news already. I have a program which puts up a modal alert with a filterProc. When the filterProc gets an update event, it does some drawing using black & white, then changes 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); 'theDialog' is the first argument passed to the filterProc. 'blackRGB' is an RGBColor containing r,g,b values of 0. My 'pltt' has black and white defined as the first two entries (about 140 entries total, all pmTolerant). The code works perfectly on all machines running System 6.0.x. Is this a known System 7 bug (I hope)? -ken -- ========== ....... ============================================= Ken McLeod :. .: UUCP: ...{spsd,zardoz,felix}!dhw68k!thecloud ========== :::.. ..::: INTERNET: thecloud@dhw68k.cts.com //// =============================================
russotto@eng.umd.edu (Matthew T. Russotto) (08/20/90)
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?
ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (08/21/90)
In all CLUT-based graphics modes, a pixel value which is all zeros is supposed to be white, while a pixel value of all ones is supposed to be black (cf Inside Mac page V-140). Is it worth checking that that FillRect call is drawing pixels that are all ones? It could be that the RGBForeColor call is mapping to a CLUT entry other than the last one (all ones), but which is also black (or nearly so). It would thus be legitimate for this CLUT entry to be redefined on an ActivatePalette, causing a change in the displayed colour (though why it would change from black to white I don't understand). Just another idea to add to the confusion... Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 The net never sleeps. It just gets knocked unconscious every now and then.
thecloud@dhw68k.cts.com (Ken McLeod) (08/25/90)
In article <1990Aug20.143954.2276@eng.umd.edu> russotto@eng.umd.edu (Matthew T. Russotto) writes: >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. >> [code omitted...] >> 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 :-) ) Well, I changed the cUpdates argument in my SetPalette call to FALSE. The behavior is still the same (window is erased to white and gets an update event when ActivatePalette() is called). I'm not too concerned yet (after all, 7.0a9 is a "voodoo" version :) ... just wanted to know if anyone else had noticed this. Incidentally, it also occurs when my app gets switched into the background: all windows in my layer are erased to white, the foreground app's windows are updated, then my windows get their update events and are redrawn. My app doesn't do anything color-related when it gets a suspend or resume event, so I suspect that something about ActivatePalette is "different" from previous System versions. -ken >Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu >][, ][+, ///, ///+, //e, //c, IIGS, //c+ --- Any questions? -- ========== ....... ============================================= Ken McLeod :. .: UUCP: ...{spsd,zardoz,felix}!dhw68k!thecloud ========== :::.. ..::: INTERNET: thecloud@dhw68k.cts.com //// =============================================