At 8:27 PM +0100 16-03-00, Richard Hartman wrote:
>So changing UI colors is accomplished by changing
>the index used to draw a particular UI element? I would've
>thought that the indexes were fixed and changing the color
>would be done by changing the RGB triplet associated with
>that index ...
Nope!
There are two different tables, and two different concepts. It's important
not to blur them together.
The palette is the mapping of index values to RGB values for the window,
screen, etc.
The UI color table is actually a list of _RGB_ values for each of the 30 or
so different types of UI elements. The RGB values are considered to be the
'truth' for this table. (The user prefs for these values are specified as
RGB, for example.)
In addition to the RGB values, we ALSO cache the index of each UI element
as found via WinRGBToIndex on the current palette. Whenever the palette
changes, these index values are recomputed, so the indexes are always up to
date.
That is, the index values in the UI color table will always reference the
palette entry that's the closest match for the UI color table's RGB value.
Note that this may not be an exact match! And it may not be the same index
after the palette is changed.
The rest of the OS just uses the index value directly, for better performance.
It's really important to understand that the UI color table entries do NOT
each have reserved slots in the palette. This actually wouldn't work most
of the time:
For 4-bpp (or less) there are only 16 positions in the palette. So
there wouldn't be room to give all 30 UI color table entries their own
index.
Some display hardware requires a fixed palette. e.g. there's an
8-bit 'direct' color model that uses 3 bits of red, 3 bits of green, and 2
bits of blue. In that model, it's impossible to give each UI element it's
own palette index as well, because that would essentially 'fix' the UI
elements.
Doing it the way we did allows you to have maximum control over the display
palette. e.g. if you create a palette that's heavily loaded with greens
for a forest picture, or with pinks and brown for people, the system alerts
and dialogs and stuff will still do a pretty decent job of appearing in the
correct colors.
Personally, I can't figure out WHY you want to use the UI colors in some
predefined bitmap.
There are only ever 2 colors at a time that apply to controls. The
foreground color and background color. If you've got a graphic control and
want to use these colors, you can just specify a 1-bpp bitmap for the image
and the OS will automatically color the off bits in the background color
and the on bits in the goreground color.
If you want to create a image that's got multiple colors but has a
non-rectangular edge, you can use the transparency feature to specify that
the 'edges' of your bitmap are transparent. Then the OS will fill the
control with the background color and draw your bitmap over the top.
So the only reason to have UI colors as indexes in a bitmap would be if you
wanted to MIX your own predefined colors with the current 'ui' colors in
the same image. That sounds pretty weird -- odds are you'd get a fairly
ugly picture if the UI colors were every changed away from their defaults.
So: what are you actually trying to accomplish? Maybe there's a better way.
--Bob
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
