Windows XP style: Why do we get a dark gray background on static text widgets?

Question

We are writing desktop applications for Windows using C ++ and Win32. Our dialogs have an ugly appearance with a "Windows XP style": the background for static text is gray. If the background of the dialog box is also gray, this is not a problem, but inside the tab control where the background is white, the gray background of the text is very noticeable.

In the past, we made a lot of our own drawings of controls, but these days we try to use the standard look'n'feel as much as possible and avoid as much as possible exceeding the standard behavior.

We are using the Win32 API, which is a bit outdated, but I think the problem even occurs with ATL. We create DIALOGTEMPLATE. The text is in the "static" control (0x0082). The only flag we set for the style is "SS_LEFT". The text control is located inside the tab control: "SysTabControl32" with only one flag: WS_CLIPSIBLINGS installed on it. I experimented with SS_WHITERECT and WS_EX_TRANSPARENT and other settings, but to no avail.

All this is obtained using the standard message handler of the Windows dialog box. My main question is: "What are we doing wrong?" not “how can I get around this?” although I would agree to the latter if no one can help me with the first.

Any ideas?

Answer 1

We do not redefine the WM_CTLCOLORSTATIC message. There is no such line in our source code, and there is nothing similar in our message handlers.

We addressed this issue by overriding the WM_DRAWITEM message for tab controls to paint their contents with a gray background (standard for dialogs without tab controls), rather than a white background (standard for contents of tab controls).

brush = CreateSolidBrush(GetSysColor(COLOR_MENU)); FillRect(lpdis->hDC, &lpdis->rcItem, brush); SetBkColor(lpdis->hDC, GetSysColor(COLOR_MENU)); wtext = ToWideStrdup(c->u.tabcontrol.Tabs[lpdis->itemID].name); rect = lpdis->rcItem; rect.top += DlgMarginY - 1; rect.bottom += DlgMarginY; DrawTextW(lpdis->hDC, wtext, -1, &rect, DT_CENTER | DT_VCENTER); free(wtext); DeleteObject(brush); 

This is obviously a workaround and not the correct answer to my question.

By the way, we initialize the “common controls”, of which, I believe, there is only one tab control using this code ... I don’t think this is due to a problem?

 #pragma comment(linker, "/manifestdependency:\"type='win32' " \ "name='Microsoft.Windows.Common-Controls' " \ "version='6.0.0.0' " \ "processorArchitecture='*' " \ "publicKeyToken='6595b64144ccf1df' " \ "language='*'\"") ... hCommCtrl = GetModuleHandle("comctl32.dll");` if (hCommCtrl) { ptrInit = (TfcInit_fn) GetProcAddress(hCommCtrl, "InitCommonControlsEx"); if (ptrInit) { data.dwSize = sizeof(INITCOMMONCONTROLSEX); data.dwICC = ctrlClass; if (ptrInit(&data) ) gCommCtrlsInitialized |= ICC_TAB_CLASSES | ICC_BAR_CLASSES; } } 

Answer 2

Accessing the MS solution for this problem requires the usual way to implement pages in a tab control: -

Instead of creating separate controls in the tab area, create a modeless child dialog box for each page and there will be controls on it. Create page dialogs with the main dialog (and not with a tab) as your parent, and the user switches between tabs, just show and hide the corresponding page dialog.

In the WM_INITDIALOG handler for each page, call the uxtheme EnableThemeDialogTexture API

With the ETDT_ENABLETAB flag ETDT_ENABLETAB this automatically changes the background color of the dialog box and all its child controls to correctly draw on the tab.

If you have overridden WM_ERASEBKGND or WM_CTLCOLOR* on your DialogProc pages, you will need to return to the default processing (return FALSE), since these methods are where the dialogue code is going to do its heavy lifting. The style bits should simply be configured as if a child page dialog was created in a dialog box with a normal 9X window.

Answer 3

The reason the background is gray is because it is the default.

To override it, you can process the WM_CTLCOLORSTATIC message in the parent window and return the custom brush.

Answer 4

Your problem is not ATL or WinAPI. In MFC, the same problem exists. Set the Tab Control tab as the parent window for Static controls. But I believe that overriding WM_DRAWITEM is a more flexible solution.

Answer 5

I have Win32 / MFC applications with shortcuts inside tabs in a dialog box, and the background color looks good on them (that is, it reflects the XP-look theme, not the flat gray) without any obvious special handling.

Under the hood, it should happen that the label sends a WM_CTLCOLOR message to its parent element, which sets the device context appropriately: the default processing in Windows should set the appropriate background color, at least for dialogs and tab controls.

One possibility is that you are doing something non-standard when processing WM_CTLCOLOR: is it overloaded somewhere in your application? Perhaps you have some old code that sets the background color of the label this way.

(Also, as Rob asks, are you using a manifest to get comctl32 6.0 into your application?)

Answer 6

After spending a huge amount of time trying to fix the problem, it would seem simple, with almost no attempt I tried almost every constant for hbrBackground.

As an amateur showed, the simplest and most effective time was to simply create a child window of the "Static" class, which covers the entire window. Another level of hack fix though