Changing the back and fore color of a control

[Vitucho]

Hi!.

I know how to change the control back and fore color of a window class, but only when inside the parent window procedure by cachting the message WM_CTLCOLOR{SHORT NAME OF CONTROL}: and establishing

SetTextColor((HDC)wParam,A COLOREF to the fore color (text color));
SetBkColor((HDC)wParam,A COLOREF to the back color of text);
return hBrush; // brush to fill the background color of the component


But if a wanna to use my own custom control with his own procedure for rewrite some behavior (apart from the graphical) and i don't want to add these lines of code into the window parent control instead how i can do it inside a control window procedure?.

So, the question is, what i have to do to modify the back and fore color of a component inside hiw own personalised window procedure. Important note: I can use the WM_PAINT message and redefine it..but in cases of list_box, combo_box this task may take some time to it, so i preffer to ask if there is anyway of simple change the colours.

THanks for reading it!.
Vitucho!.

[MikeAThon]

In the framework designed by the original authors of Windows, you probably can't. A control always defers to the parent window, and always sends its notification messages to the parent. The designers of Windows wanted it that way.

You are looking for something more OO-oriented, where the control itself is an object that does not need to rely on the existence of a parent window. Bu that's not the way it was envisioned by the Windows team, and in fact, some of these OO-principles were not even well-articulated at the time that Windows was designed.

Other frameworks allow you to do what you want. MFC, for example, tries to be more OO than the basic Windows API. In MFC, a parent window, when it receives a notification from a control, will first reflect the notification back to the control class, to see if the control class wants to handle the notification instead. MFC calls this "reflected" messages and you can search for this term.

If you are writing an API-only application, you could create a similar framework, but such a framework is non-standard for the Windows API and would not be expected by other programmers. In other words, there's no way to enforce this framework outside your own applications, and if you give your control to other programmers they will not be able to use it properly unless they also follow your (non-standard) framework.

The bottom line is that the behavior of controls, and their dependence on the existence of a parent window that cooperates and interacts with notifications to and from the control, was built in at design time of Windows.

Mike

[Vitucho]

Ok! most thanks mike!. I will keep that in mind!.
Cya!