dplatt@coherent.com (Dave Platt) (06/14/88)
I've run into an interesting problem involving the Palette Manager, and
I wonder if anybody can help me figure out a way to avoid a condition
I'm not too happy with.
I've been playing around with my Mandelbrot-set program (MandelZot),
changing its default color palette, adding more individual colors, and
laying the groundwork for a Color Picker interface. Currently, I
construct a palette whose length is no greater than the number of unique
colors supportable by the screen (e.g. 16 entries in 4-bit mode, 256
entries in 8-bit mode). The first two entries in the palette are set to
be black and white, as I.M. volume V recommends. The remaining entries
in the palette are in the form of a "contrast CLUT"... 8 entries of
[dark red, slightly brighter red, ..., full-intensity red], 8 entries of
[dark orange, slightly brighter orange, ..., full-intensity orange], and
so forth. The colors are specified as "tolerant", with a tolerance of 0
(exact match required). I've added some code to ensure that the palette
doesn't contain any two entries that have exactly the same color.
The palette works fine for drawing... I get the colors I expect.
However, things go a bit awry when I bring up a Standard Get File or
Standard Put File dialog box. The box looks OK, but if I dismiss it
(even with the "Cancel" button), I receive a color-update event... the
entire drawing region of the window is placed in the InvalRgn, and I end
up redrawing everything.
It appears as if the very act of bringing up an SFPutFile dialog box
changes the GDevice's CLUT... if I run in 16-color mode, I can see the
colors in my window change (rather garishly) when the dialog-box
appears. They change back (apparently to the correct colors) when the
dialog box is dismissed, but the Palette Manager appears to be resetting
the color environment back to its defaults and then reactivating my
palette, thus necessitating a complete redraw.
I can prevent the color-update event by passing FALSE in my SetPalette()
call, but that leaves the window very vulnerable to obnoxious color
changes... especially if it's temporarily covered over by another
window. I've tried shortening my palette, reducing the number of
entries by as much as 50% in the hope that the SFPutFile colors will
grab CLUT entries that I'm not using... no soap!
Is there any way to prevent SFGetFile and SFPutFile (or the
dialog/window-manager functions they call) from stomping on the color
environment when the dialog boxes appear? What I'd really prefer would
be to have the dialog boxes drawn using the values in the current
CLUT... they're almost certainly close enough for an acceptable-looking
dialog.
--
Dave Platt VOICE: (415) 493-8805
USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com
INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net