ChangingControlColors

Changing Control Colors
Colors can be changed for controls in the Dialogs.* family of packages from their default settings. Windows do not have a consistent method of doing things. Some methods only work for some controls and not for others. The easiest and the most consistent way is to change the system colors. To change the text color of any control is to do the following:

   OS.SystemColors.SetBrushColor(OS.SystemColors.Text, AnyColor);

However this will change the text colors of all other controls as well including those from a different application. This is highly undesirable because the computer has to be rebooted or using the control panel program to restore the original colors if the application crashes.

Before a control such as a button is drawn, ColorHandler is invoked. All the desired olors may be set here. This method only works for buttons, list boxes, edit boxes, dialog boxes, labels (static controls) and scrollbars. This does not highlight the text of an edit box or the selected entries of a list box.

Subclassing a control may be over kill because all the default actions had to be implemented. This may be the only choice for the highlighted edit box text as there is no owner draw for it.

In owner draw method, there is a field indicating if a particular entry was selected. With this information, the highlighted text problem is solved. Using the DefiningRect parameter directly causes display problems. This defining rectangle value corresponds to the dimensions for the default font and size. Another problem is that the DrawStruct field indicating the type of control drawn is unreliable. It is defined for some controls like buttons but none for status bars.

An annoying problem with all these methods is that the drawing of the control is determined by the parent. This poses no problem for controls in the Dialogs.* packages. However, it is quite messy for drawing controls in general. The ideal is to set the appropriate colors for the control and let it draw itself. The only way I could think of is to have the core library package, OS.Windows.Procs draw the controls. For example, letting OS.Windows.Procs.ColorHandler set the text and background colors and have default color drawing actions done in the owner draw handlers. These handlers may be over ridden if the default actions are not desirable. As an example, a list box default drawing action to have an optional icon on the left of the text.

As mentioned earlier, the kind of control to be drawn may be undefined in the OS.Windows.Controls.OwnerDraw.DrawStruct.Kind field. Statusbar is one such control. One would expect the following function to work:

   function To_Kind(x : OS.Unsigned)
                return OS.Windows.Controls.OwnerDraw.Kinds is
   begin
     case x is
       when 1       => return Menu;
       when 2       => return List_Box;
        ....
       when others => return Undefined;
     end case;
   end To_Kind;

When handling OS.Windows.Messages.WM_Owner_Draw, the class name of the control can then be checked when Kind is Undefined. Unfortunately this does not work for controls created by a dialog box template. For example, on my system, Kind has a value of Menu when the actual control is a status bar. A bunch of messy elsif statements are used to check the class name. At this time, I have no use for owner draw menus and so they are not implemented. Will have to revisit this problem when the need arises.

Home
Dialogs