🚀 go-pugleaf

"Mark Morrisson" <mark4@NO_SPAMvoila.fr> wrote in message
news:3ebb5ec5$1@newsgroups.borland.com...
> Hi everyone !
> I want to change the text color of a static control, <snip>

Have you looked into the WM_CTLCOLORSTATIC message? I think you can do what
you want by handleling that message in the dialog proc.

Hope that helps,
Gary

Hi Gary,
Thanks for your reply. No, I fear I can't handle the WM_CTLCOLORSTATIC
message because I create an array of labels and it wouldn't be smart to test
each
window handle in the switch statement :

case WM_CTLCOLORSTATIC:
{
 HDC hdc = (HDC) wParam;
 HWND hwndCtl = (HWND) lParam;

 switch (hwndCtl)
 {
  case label[0]:
  case label[1]:
  case label[2]:
...
  case label[99]:

  SetTextColor(hdc, RGB(0, 0, 192));
  return 0;
 }
 break;
}

But I'd like to know why the subclassing solution doesn't work... When I
apply it to a
control created in the resource file with CTEXT, for instance, it works
fine. But when
I apply it to a control created on the fly, it doesn't work... Why ?

Mark

<snip>.. But what intrigued me is that text was displayed all the same...

This makes me think that your subclassing did not work. If you want, you can
still post a small working sample.

> In fact, it's the
> SetWindowText function that drew the text.
WM_PAINT paints the text.

> The SetWindowLong function is the only method I found (with SetProp) to
> store the text of a label.

SetWindowText and SetDlgItemText are the low level functions for storing
text.
I've never needed anything else.

>
> About the multiple labels, of course it prevents me from using the
> CTLCOLORSTATIC
> methos because it forces me to put lots of "case" statements in the switch
> statement...
> Since all variables tested in the "case" statements will be HWND, I don't
> see any
> way to determine its associated color in one instruction... I mean, I'm
not
> certain
> that all these HWND's will form a serie (like 41001, 41002, 41003, etc).
>
Give the controls you want to work with an ID (see the hMenu param of
CreateWindow[Ex])
Then use GetDlgCtrlID in the WM_CTLCOLORSTATIC handler to get the ID back.

Hope that helps
Gary

Hi Gary !
I hope you're doing fine. Well, I gave you all the pieces of code that do
the subclassing
along my previous posts. The subclassing does work, I have set up a debug
point inside
the new WM_PAINT handler. And I can -assure- you that WM_PAINT isn't called
when SetWindowText is called, only WM_SETTEXT is called. The default handler
of WM_SETTEXT stores the text in an internal buffer, and displays it (that's
why you
can call SetWindowText at any moment). If I don't intercept WM_SETTEXT, then
Windows displays the text, and when my WM_PAINT handler is called, it writes
over
the previous displayed text. Since I reduced the font, I can still see the
text displayed
by Windows behind my new text. Look at Win32.hlp, it says that SetWindowText
stores the text and a buffer AND display it, without calling WM_PAINT.

Your idea to use the hMenu parameter in CreateWindow is pretty good, I
hadn't
thought of it. But I guess that subclassing is a bit "cleaner", don't you
think ?

Have a nice day,
Mark

<snip>
> But I guess that subclassing is a bit "cleaner", don't you
> think ?
>
<snip>
Clean can mean different things to different people.
If the code for changing the text color using subclassing was more
straightforward then the code using WM_CTLCOLORSTATIC, then you could say
subclassing is cleaner.

However, subclassing and handling WM_PAINT gets you involved in more things
then you need to. Handling WM_CTLCOLORSTATIC gives you a chance to do what
you need to do and nothing more.

Generally, I only subclass when I need to trap messages that only go to the
control. I had a similar need to yours in one project, used
WM_CTLCOLORSTATIC and was happy with the result. Try both methods. See what
is clean straightforward and easy to understand for you.

Best of luck,
Gary

Ok, Gary, you're right, your method is more straightforward than mine.
I thank you again for your advices and I hope all goes well.
Mark