Though they are relatively well covered in the documentation, presentation parameters and system colors (or at least their proper usage) are not well known. Part of the problem is that their relationship to the standard controls, their relationship to each other, and how custom controls should use them in order to be good citizens is definitely not explained clearly enough.
The Standard Controls
The best way to see the intended use of presentation parameters (or presparams as they are called) and system colors is to look at how the standard PM controls use them. A basic requirement of the standard controls (because of how widely they are used) is that they be configurable to the greatest degree practical. An obviously important area of configurability for a control is that of the colors and fonts used in drawing itself. So they all have a logic kind of like this:
So, when you use the system color palette to set a system wide color (by holding down Alt when you drag and drop a palette color), you are setting a particular system color. You can also do this via your own programs, so you can create your own system palette manager if you desire. There is nothing magical about the system palette widget. So every window which has not had presentation color X explicitly set on it will use the new system color Y. In order to make everyone update immediately, every window is sent a WM_SYSCOLORCHANGE message and the screen is redrawn by invalidating all windows.
In order to allow particular windows to buck the trend and have their own color/font scheme (while still remaining user configurable), PM supports presentation parameters. PM supports a predefined set of presentation parameters which are used by the standard controls (and user programs if they care about presentation parameters at all.) Dropping a color on a window (without holding Alt) will cause the new presparam to be stored on the window and a WM_PRESPARAMCHANGED message to be sent to it. Its reaction will be similar to the WM_SYSCOLORCHANGE discussed above. Presentation colors/fonts are set via the WinSetPresParam() API and queried via WinQueryPresParam(). They can be removed via WinRemovePresParam(). The WinQueryPresParam() API will automatically search up the ownership chain of the target window, if you ask it to, searching for some ancestor window with that particular presentation parameter. I assume that this is intended to allow a single owner window to control the appearance of its owned windows. When a color or font is dropped on a window, PM just calls WinSetPresParam() on that window.
The important things to remember here are that system colors only have to be stored once for the whole system and that all windows call APIs, WinQuerySysColor() in this case, to get their values. Presentation parameters are stored separately for each window on which they are set. PM maintains this storage for you and keeps each window's presparams associated with the correct window handle.
Don't try to read any rhyme or reason into the names of the system/presentation colors used by a window for a particular attribute of its appearance. There are a set of predefined, and pretty generically named, colors. In order to avoid massive proliferation of them, the standard controls will just pick from that list ones with names that are hopefully somewhat related to the purpose for which they are used (but sometimes seemingly unrelated at all.) The documentation on what standard controls use what colors, is extremely pathetic. So its only through the patient experimentation of you and/or others that most of them get figured out. If you have IBM on-line documentation, open the PM Reference and search for "Default Colors" to get about as much as you are likely to find. And even this documentation only says what they system/pres colors are, not what visual aspect of the control they are used for.
Blending Into the Crowd
So, if you want to write a control window that acts like a standard control in its use of colors and fonts, you must take a couple of steps. The most obvious is to write a wrapper function that takes a system color and a presentation color. It will first look for the presentation parameter and return it if found, else it will query the system color and return that. This function then provides the basis for the paint logic's use of colors, while moving lots of possibly replicated grunt code to one place.
You can take two approaches to the presentation colors and system colors your window uses. You can either just be very stateless and query them on every paint, or you can cache them. In the later scheme, you set them initially via a manual query and thereafter update them on any WM_SYSCOLORCHANGE or WM_PRESPARAMCHANGED message. Your window class would just call, for instance, a SaveColors() function initially upon creation and then upon receipt of either message thereafter. This would keep all of the code in the same place.
Custom Presentation Parameters
You can create your own presentation parameters by using values greater than PP_USER. The system will not send them to you of course since it doesn't know them from Adam, but you can send them to your own windows. If you set them on 'foreign' windows they will just be ignored (though PM will store them on the window anyway) because those windows will not understand them. Worse, they might have defined their own custom params with the same id (and different data layout) and freak out.
Saving/Reload Presentation Parameters
The WinStoreWindowPos() and WindowRestoreWindowPos() APIs will save and restore the size, position, and presentation parameters of a window. The information is stored in the system INI file, so you have to provide the application and key names to use. These may or may not be very useful to you, and the same functionality is pretty easy replicated on your own if these do not do exactly what you want.
Copyright Notice
| Reply to Author
| Search
| Section Index
| Previous Page
| Next Page
If you see a problem with this web site, contact
edm2_eds@iqpac.com.