Browse Prior Art Database

Overcoming Color Deficiencies in OS/2 Controls When Using the Color Palette

IP.com Disclosure Number: IPCOM000111764D
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 2 page(s) / 104K

Publishing Venue

IBM

Related People

Johnson, D: AUTHOR [+2]

Abstract

Color support for OS/2* Presentation Manager* (PM) applications changed from OS/2 1.3 to OS/2 2.0, and some of the PM controls have not kept up with the changes. For OS/2 1.3, colors were changed by the user by modifying predefined system colors. After the change, all colors that were defined by the system to be painted in that system color would be painted in the newly-designated color.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Overcoming Color Deficiencies in OS/2 Controls When Using the Color
Palette

      Color support for OS/2* Presentation Manager* (PM) applications
changed from OS/2 1.3 to OS/2 2.0, and some of the PM controls have
not kept up with the changes.  For OS/2 1.3, colors were changed by
the user by modifying predefined system colors.  After the change,
all colors that were defined by the system to be painted in that
system color would be painted in the newly-designated color.

      For OS/2 2.0, however, a color palette was provided to the
user.  The user could create any RGB color they chose with the
palette and drop that color onto any object in the system.  They
could also cause system-wide color changes using the palette colors,
if desired.

      Unfortunately, some OS/2 1.3 PM controls, such as the container
and the notebook, have not kept up with these changes in their move
to OS/2 2.0.  When a color from the color palette is dropped on these
controls, the color the control subsequently paints is often not the
correct color.  In some cases it is a different shade, and in some
cases the controls just paint with grey.  Since other types of
controls paint the correct color, it is unacceptable for these
controls to paint incorrectly.

      Before the color palette, system colors were based on indices
into a predefined system color table.  The only choices available to
the user were those that were predefined.  Even if the user chose
something else, they would get the predefined color that most closely
corresponded to an index in the color table.

      Using the color palette, the user is no longer restricted in
this manner.  They can define any RGB color they choose and expect
that color to be used.  Since some PM controls may not honor this
color choice, the application has to take over the color painting for
these controls.  An example of such a situation is for the painting
of the background of the container control.

      The first thing the application must do is to determine the RGB
color value that must be used.  This is done using the
WinQueryPresParam call for the type of color in question (foreground,
background, ...).

      Next, the application creates its own logical color table to
use for the painting.  Since only one color is being painted, the
application only needs to create a one element logical color table.
This is created with the GpiCreateLogColorTable API, specifying the
color table be reset, that RGB colors are being used, and the color
desired.

      The application is then ready to paint in the desired color.
Because the current color table was created with the exact RGB color
desired, a call such as WinFillRect can be used to fill an area with
the color.  This call requires an index into the current color table.
Passing the RGB color will now work to paint the exact desired co...