whats the right way?

[mark smit]

Hello all!

Could someone out there please enlighten me on how to change the color of the client area of a window on the fly? I am writing a small vector editor and I would like to be able to change the background color, but I'm confused on how to handle the "brush" used in the main window class.

wndclass.hbrBackground = %COLOR_APPWORKSPACE

Should I create a new brush and use SetClassLong() to reassign the background brush? and if so, do I have to delete it?

Cheers!

[Lance Edmonds]

There are a few ways:

1. Specify a NULL for the class-brush and then process %WM_ERASEBKGND messages and paint the background yourself.

2. Intercept %WM_PAINT and draw the background. In this case yo also need to intercept %WM_ERASEBKGND and return %TRUE so that the background is not handled by the default handler which could cause flicker.

3. Place a (static) control over the entire client area, subclass it, and handle it's %WM_PAINT and %WM_ERASEBKGND messages.

Personally, I find approach #2 works well.

When you want to change the background, call InvalidateRect() followed by UpdateWindow(). This forces the %WM_PAINT handler to be executed immediately, rather than waiting for the message queue to empty first (which is the normal way Windows generates %WM_PAINT messages).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[mark smit]

Hello Lance!

Would the following be acceptable?

1. create WNDCLASS and use %COLOR_APPWORKSPACE for default brush
2. on WM_CREATE, CREATESOLIDBRUSH(RGB),SETCLASSLONG(BRUSH)

to change color...

3. GETCLASSLONG(BRUSH), DELETEOBJECT(BRUSH)
4. CREATESOLIDBRUSH(RGB), SETCLASSLONG(BRUSH)

do other stuff

I read somewhere in the MSDN that windows will delete the brush in the window class of the current instance. What do you think of this?

Cheers!

------------------

[Lance Edmonds]

It should work fine, as long as it works I'm not aware of any issues with this method. Yes, Windows should destroy the class brush when the window is destroyed - this is documented in WIN32.HLP on the "WNDCLASS" structure.

One note: the WndClass.hbrBackground value should have 1 added to it - this is a "left-over" from Win16. This is also documented in WIN32.HLP

ie:

WndClass.hbrBackground = %COLOR_APPWORKSPACE + 1

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[K Peel]

Don't forget %WM_CTLCOLORDLG if you are using a dialog box,

        Case %WM_CTLCOLORDLG
             Function = MyDlgColor

Then to change the window color, set the MyDlgColor variable to a new brush, and invalidate the window background.


------------------
Kev G Peel
KGP Software
Bridgwater, UK.
mailto:[email protected][email protected]</A>

[Lance Edmonds]

Unlike the class brush used in a real window, Kev's suggestion for a dialog box required that the brush is destroyed when the dialog is destroyed (ie, you have to process %WM_DESTROY and use DeleteObject() on the brush handle).

Also, because %WM_CTLCOLORDLG is only sent to a dialog's callback to get the background color ahead of redrawing the background, you do _not_ need to explicitly invalidate the client area during processing of this message.

However, if you wanted to change the color elsewhere in your code, you would employ InvalidateRect() to trigger the repaint sequence.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>