Weird static control/dialog box issue...

Started by
15 comments, last by jwezorek 13 years, 11 months ago
Quote:Original post by jwezorek
Anyway, I'm not sure what's going on with your painting issues. Trying setting the WS_TRANSPARENT style on your static controls, I guess, but you shouldn't have to...


I tried that, but it didn't work.

I have a feeling I'm going to have to break down and code the dialogs by hand (no templates). It sure would be nice to know why this is happening though...

No, I am not a professional programmer. I'm just a hobbyist having fun...

Advertisement
I have had a similar painting problem with the message WM_ERASEBKGND where my whole client area was coming out white when it should have been blue. This may also be happening with your statics. If you comment out the return(false); line (in the WM_ERASEBKGND message area) you may knowtice that the statics wont be white anymore but that may cause other problems depending on what your program does & how much painting it does.

case WM_ERASEBKGND:     //return(false);break;
You could try handling WM_CTLCOLORSTATIC. From the docs, "If a dialog box procedure handles this message, it should cast the desired return value to a INT_PTR and return the value directly. If the dialog box procedure returns FALSE, then default message handling is performed." So it seems like the "default message handling" is what is screwing it up: try overriding it by returning a brush that is the background color of the dialog, and also set the background mode of the HDC to transparent. So something like
case WM_CTLCOLORSTATIC:    HDC hdc = (HDC) wparam;   SetBkMode(hdc, TRANSPARENT);   return (INT_PTR) CreateSolidBrush(GetSysColor(COLOR_WINDOW));

I'm pretty sure you're supposed to let Win32 own the brush after this i.e. don't delete it, but make sure.
Quote:Original post by jwezorek
You could try handling WM_CTLCOLORSTATIC. From the docs, "If a dialog box procedure handles this message, it should cast the desired return value to a INT_PTR and return the value directly. If the dialog box procedure returns FALSE, then default message handling is performed." So it seems like the "default message handling" is what is screwing it up: try overriding it by returning a brush that is the background color of the dialog, and also set the background mode of the HDC to transparent. So something like
case WM_CTLCOLORSTATIC:    HDC hdc = (HDC) wparam;   SetBkMode(hdc, TRANSPARENT);   return (INT_PTR) CreateSolidBrush(GetSysColor(COLOR_WINDOW));

I'm pretty sure you're supposed to let Win32 own the brush after this i.e. don't delete it, but make sure.


That did it! Thanks!

No, I am not a professional programmer. I'm just a hobbyist having fun...

Good, I'm just not sure why this became necessary. Something with XP-style and Vista-style controls I guess. I don't think WM_CTLCOLORSTATIC used to even exist but my memory might be faulty.
It seems totally unnecessary. If the "new style" windows have a colored background by default, it stands to reason that the text should be transparent. But, I digress... Progress is progress.

No, I am not a professional programmer. I'm just a hobbyist having fun...

FYI, guys in comments here are saying that you do have to delete the brush even though the docs say you don't. Not sure who's right but I'd probably err on the side of the commenters.

EDIT: or actually just return GetSysColorBrush(COLOR_WINDOW) and then it's not an issue.

This topic is closed to new replies.

Advertisement