Sign in to follow this  
MarkS

Weird static control/dialog box issue...

Recommended Posts

I am having some trouble with static text in dialog boxes under Windows. If I use CreateDialog with a pointer to a dialog proc or if I use DialogBox I get this: (Wrong) However, if I use CreateDialog with NULL in place of the dialog proc, I get this: (Correct) I'm going to need a dialog proc. Why is this happening and how do I stop it? There should not be a white box behind the text. I've scoured MSDN, but there is no mention of this. There is precious little information available on the static text control period. Any ideas?

Share this post


Link to post
Share on other sites
Are you drawing the labels "Deadhead Miles ..." etc. using the function TextOut?
If so, I have had this problem, you need to set the background as transparent.
use SetBkMode(hdc, TRANSPARENT);

If those labels are static controls like CreateWindowEx(0,"Static","Deadhead Miles",...); then I am not sure but there maybe a Flag you can use like SS_TRANSPARENT or something to make the background transparent, but I never get a white background when I use static controls.
Check the flags you have for the static control, something like the below would intentionally create the error you are getting...

CreateWindowEx(0,"Static","DeadheadMiles",WS_BORDER|WS_CHILD|WS_VISIBLE|SS_WHITERECT,x,y,100,20,...);

Share this post


Link to post
Share on other sites
I'm using a dialog template created with a resource editor.


DRIVER_DLOG DIALOG 0, 0, 370, 150
STYLE DS_SETFONT | WS_BORDER | WS_POPUP | WS_VISIBLE | WS_SYSMENU | WS_CAPTION
CAPTION "Edit Driver Information..."
FONT 10, "MS SHELL DLG"
BEGIN
CONTROL "OK",IDOK,"BUTTON",BS_DEFPUSHBUTTON |BS_VCENTER |BS_CENTER |WS_CHILD |WS_TABSTOP |WS_VISIBLE ,100,125,50,14
CONTROL "Cancel",IDCANCEL,"BUTTON",BS_PUSHBUTTON |BS_VCENTER |BS_CENTER |WS_CHILD |WS_TABSTOP |WS_VISIBLE ,220,125,50,14
CONTROL "Single",3,"BUTTON",BS_RADIOBUTTON |BS_LEFT |WS_CHILD |WS_TABSTOP |WS_VISIBLE ,220,80,50,14
CONTROL "Married",4,"BUTTON",BS_RADIOBUTTON |BS_LEFT |WS_CHILD |WS_TABSTOP |WS_VISIBLE ,275,80,60,14
CONTROL "",5,"EDIT",ES_AUTOHSCROLL |ES_LEFT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,60,8,200,13
CONTROL "0.00",6,"EDIT",ES_AUTOHSCROLL |ES_RIGHT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,110,48,40,13
CONTROL "0.00",7,"EDIT",ES_AUTOHSCROLL |ES_RIGHT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,110,63,40,13
CONTROL "0.00",8,"EDIT",ES_AUTOHSCROLL |ES_RIGHT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,110,78,40,13
CONTROL "0.00",9,"EDIT",ES_AUTOHSCROLL |ES_RIGHT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,110,93,40,13
CONTROL "Driver Name:",10,"STATIC",SS_SIMPLE | SS_LEFT |WS_CHILD |WS_GROUP | WS_VISIBLE,10,10,44,10
CONTROL "0",11,"EDIT",ES_NUMBER |ES_AUTOHSCROLL |ES_RIGHT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,310,48,40,13
CONTROL "0.00",12,"EDIT",ES_AUTOHSCROLL |ES_RIGHT |WS_CHILD |WS_TABSTOP |WS_VISIBLE | WS_BORDER,310,63,40,13
CONTROL "Deadhead Miles Pay Rate:",13,"STATIC",SS_LEFT |WS_CHILD |WS_GROUP |WS_VISIBLE ,20,50,85,10
CONTROL "Live Miles Pay Rate:",14,"STATIC",SS_LEFT |WS_CHILD |WS_GROUP |WS_VISIBLE ,20,65,85,10
CONTROL "Cushion Miles Pay Rate:",15,"STATIC",SS_LEFT |WS_CHILD |WS_GROUP |WS_VISIBLE ,20,80,85,10
CONTROL "Hourly Pay Rate:",16,"STATIC",SS_LEFT |WS_CHILD |WS_GROUP |WS_VISIBLE ,20,95,85,10
CONTROL "Allowances (Line 5 on W-4):",17,"STATIC",SS_LEFT |WS_CHILD |WS_GROUP |WS_VISIBLE ,180,50,107,10
CONTROL "Additional Withholding (Line 6 on W-4):",12,"STATIC",SS_LEFT |WS_CHILD |WS_GROUP |WS_VISIBLE ,180,65,125,10
CONTROL "Pay Rate",18,"BUTTON",BS_GROUPBOX |WS_CHILD |WS_VISIBLE ,10,35,150,80
CONTROL "W-4 Information",19,"BUTTON",BS_GROUPBOX |WS_CHILD |WS_VISIBLE ,170,35,190,65
END



And the dialog proc. VERY basic right now...

bool CALLBACK DriverDialogProc(HWND hwndDlg,UINT message,WPARAM wParam,LPARAM lParam)
{
switch(message)
{
case WM_INITDIALOG:
CheckDlgButton(hwndDlg,3,true);
return(true);
case WM_ERASEBKGND:
return(false);
case WM_COMMAND:
switch(LOWORD(wParam))
{
case IDOK:
case IDCANCEL:
EndDialog(hwndDlg,wParam);
return(true);
}
break;
}
return(false);
}

Share this post


Link to post
Share on other sites
Quote:
Original post by jwezorek
When interacting with Win32 you should use TRUE and FALSE rather than than true and false. I doubt that's your problem, however.


Nope. No effect. I am curious why though? Besides, I like the pretty blue letters!

Share this post


Link to post
Share on other sites
Quote:
Original post by maspeir
Quote:
Original post by jwezorek
When interacting with Win32 you should use TRUE and FALSE rather than than true and false. I doubt that's your problem, however.


Nope. No effect. I am curious why though?


Because TRUE and FALSE are #define's that are defined somewhere in "windows.h", as I think 1 and 0 respectively. They pre-date the addition of the true and false reserved words to C++. I don't think true and false in C++ are guaranteed to equal 1 and 0, just not-zero and zero. (somebody correct me if I'm wrong on this...)

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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;



Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this