i'm trying draw a rectangle roundend around of control, i've done something like this:
LRESULT CALLBACK WindPorc(HWND hwnd, UINT umsg, WPARAM wparam, LPARAM lparam)
{
case WM_CTLCOLOREDIT:
{
// device handle
HDC Chdc = (HDC)wparam;
// handle to control
HWND CHand = (HWND)lparam;
// new object pen...
HPEN penx = CreatePen(PS_SOLID, 5, RGB(0, 255, 255));
// apply pen to device handle and back up the original handle
HGDIOBJ objb = SelectObject(Chdc, penx);
// auto...
RECT rectx;
GetClientRect(CHand, &rectx);
// Now draw the rect with round borders...
RoundRect(Chdc, (rectx.left -2), (rectx.top - 2), (rectx.right + 2), (rectx.bottom + 2), 5, 5);
// reset device hand...
SelectObject(Chdc, objb);
// Set text color...
SetTextColor(Chdc, RGB(0, 255, 255));
// clean up...
DeleteObject(penx);
DeleteObject(objb);
// I should return a brush for the bk, but this don't care now...
//return;
}
}
void InitUI()
{
// just the edit control, isn't need the RegisterClass etc...
HWND Edit1 = CreateWindowEx
(
NULL,
L"EDIT",
NULL,
WS_CHILD | WS_VISIBLE |
ES_LEFT | ES_MULTILINE, // Just a demonstration, it should be ES_PASSWORD
10, 120, 200, 22,
winx, // parent window HWND...
(HMENU)TEXTBOX_1, // id
(HINSTANCE)GetWindowLong(winx, GWL_HINSTANCE),
NULL
);
}
ok, this would look like this:
but if i change the style on CreateWindowEx(); to ES_PASSWORD the edges disappear, leaving something like this:
Why do they disappear?
I would say the implementation is wrong in multiple ways:
Chdc is a DC that can draw on the client area of the edit control only, while you want to draw on the parent window's (dialog's) client area.
GetClientRect() always returns (0,0) for the top-left corner, as the rectangle is relative to... the edit control itself.
WM_CTLCOLOREDIT may not be the best place to draw the rectangle, you need to make some tests to check when this message is actually called.
If you wish to keep the implementation this way, you should:
Draw using the parent window's DC, not the edit control's one.
Instead of GetClientRect() call GetWindowRect() and then ScreenToClient() to make coordinates relative to the parent window's client area.
Use the WM_PAINT message (and the BeginPaint()/EndPaint() functions) to get a DC for the parent window.
I would consider a different implementation though, create an Owner-Drawn Static Control, some few pixels larger than the edit control, placed somehow "around" the edit control (set the WS_CLIPSIBLINGS style to make sure that the edit control stays on top of the static one). Drawing should be carried-out processing the WM_DRAWITEM message. I think this implementation is more robust.
Related
I have window with gradient background. Combobox have own background brush.
How can I remove white corner in combobox? How can I change brush or another way.
On picture white corner marked by red frame.
I create combobox as:
DWORD dwStyle = WS_CHILD | CBS_DROPDOWNLIST;
if (m_bVisible) dwStyle |= WS_VISIBLE;
m_hWnd = CreateWindow(WC_COMBOBOX, NULL, dwStyle,
m_posX, m_posY, m_width, m_height, m_hParent, (HMENU)m_id, m_hInstance, NULL);
I tried changing background brush with message WM_CTLCOLOREDIT, but no effect:
case WM_CTLCOLOREDIT:
if ((HWND)lParam == m_hSrcListBox)
{
return (LRESULT)m_hBrush;
}
break;
=== SOLVED. WORK VERSION ===
First way.
In parent WndProc:
case WM_CTLCOLORSTATIC:
if ((HWND)lParam == m_hSrcListBox)
{
return (LRESULT)m_pSrcListBox->GetHbrush();
}
break;
In my class:
//
// CListBox::GetHbrush().
//
// Get brush.
//
HBRUSH CListBox::GetHbrush()
{
if (!m_hBrush)
{
m_hBrush = CreateTransparentBackgroundBrush(m_hParent, m_hWnd);
}
return m_hBrush;
}
Create transparent background:
//
// CListBox::CreateTransparentBackgroundBrush().
//
// Create transparent background for element.
//
HBRUSH CListBox::CreateTransparentBackgroundBrush(HWND parent, HWND client)
{
RECT rct;
POINT p1;
POINT p2;
GetWindowRect(client, &rct);
p1.x = rct.left;
p1.y = rct.top;
ScreenToClient(parent, &p1);
p2.x = rct.right;
p2.y = rct.bottom;
ScreenToClient(parent, &p2);
HDC hdcParent = GetDC(parent);
HDC hdcClient = GetDC(client);
HDC hdcmem = CreateCompatibleDC(hdcClient);
HBITMAP hbitmap = CreateCompatibleBitmap(hdcClient, p2.x - p1.x, p2.y - p1.y);
SelectObject(hdcmem, hbitmap);
BitBlt(hdcmem, 0, 0, p2.x - p1.x, p2.y - p1.y, hdcParent, p1.x, p1.y, SRCCOPY);
HBRUSH pattern = CreatePatternBrush(hbitmap);
DeleteDC(hdcmem);
DeleteObject(hbitmap);
ReleaseDC(client, hdcClient);
ReleaseDC(parent, hdcParent);
return pattern;
}
Second way.
In parent WndProc draw background in WM_ERASEBKGND message, then the corners will not.
case WM_ERASEBKGND:
m_hdc = (HDC)wParam;
// draw background.
return TRUE;
break;
The result of both methods:
For dialog boxes, handle WM_CTLCOLORDLG and return a background brush for the combobox
If you are displaying this combobox in a dialog, the trick is actually to handle the WM_CTLCOLORDLG message in your dialog's window procedure. In response to this message, you return a handle to a brush that the dialog box will use to paint its background.
case WM_CTLCOLORDLG:
{
// NOTE: This code is wrong because it creates a new brush object each time it processes
// the message, which it promptly leaks. It is merely for demonstration purposes.
// Normally, you would create the brush once, in response to WM_INITDIALOG,
// cache it away, and return that same cached handle each time, finally destroying
// the brush in response to WM_NCDESTROY.
HBRUSH hBrush = CreateSolidBrush(RGB(255, 120, 0));
return reinterpret_cast<INT_PTR>(hBrush);
}
This is the standard, documented way of changing the background color of a dialog box, and it also solves the problem with the combobox. Apparently, for whatever reason, combobox controls also use this brush to paint their background. I suppose they send a WM_CTLCOLORDLG message to their parent when they are painting themselves.
Of course, this limits you to the graphics capabilities of a GDI brush. You can draw any system or solid color that you want, or even use a hatch or pattern/bitmap brush, but there is no simple way of creating a gradient brush. (GDI+ has one, but not GDI.) Normally it wouldn't matter—you'd just call the GradientFill function in your WM_PAINT (or even WM_ERASEBKGND) message handler. That works fine for the dialog's background, but the combobox still draws its background with the brush returned by WM_CTLCOLORDLG, so it still has those 4 dots on its corners drawn in COLOR_3DFACE (which is the brush that the default dialog procedure returns).
Returning a null brush (NULL_BRUSH/HOLLOW_BRUSH) from WM_CTLCOLORDLG doesn't work, either. It changes the appearance slightly, such that the upper-right and lower-left corner pixels are now filled with something that looks like COLOR_3DSKSHADOW, but they are still visibly filled with a color other than the actual background gradient.
So if you really want it to look nice, you are left with only a single option: returning a handle to a GDI brush. And of course, it needs to be the same brush as is used to draw the dialog's background.
If you want a gradient fill, the only solution I can think of is using a pattern/bitmap brush, where the bitmap (DDB or DIB) is your gradient. Not great, but at least the days of Windows 9x limiting us to 8×8 patterns are long gone. Maybe someone more inventive than me can use this information to think of a better workaround?
For other windows, handle WM_CTLCOLORSTATIC and return a background brush for the combobox
All of that for a dialog box. But what about if you are displaying the combobox in a standard window (i.e., something other than a dialog box)? The WM_CTLCOLORDLG message is never sent in this case.
Instead, the combobox sends a WM_CTLCOLORSTATIC message to its parent window, and then uses the brush handle returned in response to that message to paint its background.
This is weird, I know. I only stumbled across it by conducting empirical tests, and I'm not sure quite sure what the rationale was. If I had to guess, I'd say that the CBS_DROPDOWNLIST style makes the combobox non-editable (i.e., it's not a true combobox because there is no Edit control), so instead of WM_CTLCOLOREDIT, it uses WM_CTLCOLORSTATIC. A disabled Edit box sends WM_CTLCOLORSTATIC, too, and so does a disabled combobox with the "normal" CBS_SIMPLE and CBS_DROPDOWN styles.
Weirder still, this only happens when the Aero theme is enabled (Vista and 7). It doesn't happen on Windows 10, or with the Luna theme (Visual Styles under XP), or with the Classic theme. (I didn't test on Windows 8 or 8.1.) Not that it matters, I suppose, since all of those other themes draw a simple rectangular combobox, leaving no corner pixels for the background to show through.
Whatever the logic, the solution remains to handle the WM_CTLCOLORSTATIC message and return the brush you wish the combobox to use to paint its background.
The same considerations apply here as those discussed above for the dialog box. If your window uses a solid-color background or a system color, you are home-free. Simply return a handle to the same brush that you set as the window class's background brush. If you want to use a gradient, you'll need to figure out a way to represent that gradient in the form of a GDI brush.
WNDCLASSEX wcex;
wcex.cbSize = sizeof(WNDCLASSEX);
wcex.style = CS_HREDRAW | CS_VREDRAW;
wcex.lpfnWndProc = WndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = hInstance;
wcex.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDR_APPLICATION));
wcex.hIconSm = LoadIcon(hInstance, MAKEINTRESOURCE(IDR_APPLICATION_SMALL));
wcex.hCursor = LoadCursor(NULL, IDC_ARROW);
wcex.hbrBackground = reinterpret_cast<HBRUSH>(COLOR_3DDKSHADOW + 1); // background brush
wcex.lpszMenuName = NULL;
wcex.lpszClassName = TEXT("My Colored Window Class");
RegisterClassEx(&wcex);
case WM_CTLCOLORSTATIC:
{
// NOTE: No leak here because we're using a system brush in this example.
return reinterpret_cast<LRESULT>(GetSysColorBrush(COLOR_3DDKSHADOW)); // background brush
}
How can i remove white corner in combobox?
I don't know if there is a more official way to get rid of it, but one option would be to create a Region with rounded corners using CreateRoundRectRgn(), and then apply it to the ComboBox using SetWindowRgn(). That will mask off the corners.
With this call
SystemParametersInfo(SPI_SETCLIENTAREAANIMATION, 0, (LPVOID)FALSE, 0);
I disable the animation of buttons in my Win32 C++ project (no MFC or anything else) that has Visual Styles Common Controls 6.0.0.0 enabled and correctly initialized by calling InitCommonControlsEx function. Is there an alternative method to do this? I am asking because I don't want to disable the animation for the whole system but ONLY for my application. The buttons I create are Custom Drawn (not Owner Drawn).
I create a button like this in the WM_CREATE message (hwndbutton is defined before as static so that I can share it between all WM messages):
hwndbutton = CreateWindowEx(0, L"BUTTON", L"example", WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON, x, y, width, height, hwnd, (HMENU)button_id, GetModuleHandle(NULL), NULL);
and I draw it
...
case WM_NOTIFY:
{
LPNMHDR item = (LPNMHDR)lParam;
if (item->idFrom == button_id && item->code == NM_CUSTOMDRAW)
{
LPNMCUSTOMDRAW item_draw = (LPNMCUSTOMDRAW)item;
if (item_draw->uItemState & CDIS_HOT)
{
SetDCBrushColor(item_draw->hdc, RGB(180, 180, 180));
SelectObject(item_draw->hdc, GetStockObject(DC_BRUSH));
}
else
{
SetDCBrushColor(item_draw->hdc, RGB(255, 255, 255));
SelectObject(item_draw->hdc, GetStockObject(DC_BRUSH));
}
SetDCPenColor(item_draw->hdc, RGB(0, 0, 0));
SelectObject(item_draw->hdc, GetStockObject(DC_PEN));
RoundRect(item_draw->hdc, item_draw->rc.left, item_draw->rc.top, item_draw->rc.right, item_draw->rc.bottom, 0, 0);
return CDRF_DODEFAULT; // Return would be CDRF_SKIPDEFAULT but I want to keep the text "example" drawn
}
break;
...
By "button animation", I mean for example the fading effect that takes place in the button color when you move the cursor over a button and then leave it: I would like it to be colorA when normale state or colorB when mouse is over and not colorA when normal and fade_until_you_reach_colorB when mouse is over.
Thanks
EDIT: I add two gifs
The first is what I want (and I obtain with a previous call to SystemParametersInfo) and the second is the animation I would like to avoid
What I want
What I DON'T want
Theme for individual windows and controls can be disabled as follows:
SetWindowTheme(hbutton, L" ", L" ");
Animation should already be disabled because you are using custom draw. This method will also disable mouse-hover effect.
Normally when you disable a button's theme it may look weird with old 3-D borders on newer systems. You can add BS_FLAT to button's style.
Here is how the program looks as it starts :
http://oi58.tinypic.com/2dwgs4h.jpg (can't upload images if I have less than 10 rep, sorry)
As soon as I hover with the cursor to change tab, every control which is not a child of the tabcontrol gets painted over in white as shown here :
http://oi61.tinypic.com/2yvuiwl.jpg
Here is how I created the TabControl in WM_CREATE:
RECT client_rect;
GetClientRect(hwnd, &client_rect);
TabControl = CreateWindowEx(WS_EX_COMPOSITED, WC_TABCONTROL, L"", WS_CHILD | WS_VISIBLE | WS_CLIPCHILDREN,
10, 10, client_rect.right - client_rect.left - 20,
client_rect.bottom - client_rect.top - 20, hwnd, (HMENU)110, GetModuleHandle(NULL), NULL);
TCITEM tab_info;
memset(&tab_info, 0, sizeof(tab_info));
tab_info.mask = TCIF_TEXT;
tab_info.pszText = L"Encoder";
tab_info.cchTextMax = 5;
SendMessage(TabControl, TCM_INSERTITEM, 0, (LPARAM)&tab_info);
tab_info.pszText = L"Decoder";
SendMessage(TabControl, TCM_INSERTITEM, 1, (LPARAM)&tab_info);
tab_info.pszText = L"Info Tab ";
SendMessage(TabControl, TCM_INSERTITEM, 2, (LPARAM)&tab_info);
RECT tab_rectangle;
GetClientRect(TabControl, &tab_rectangle);
SendMessage(TabControl, TCM_ADJUSTRECT, FALSE, (LPARAM)&tab_rectangle);
DefaultTabProc = (WNDPROC)SetWindowLongPtr(TabControl, GWL_WNDPROC, (LONG_PTR)TabProc);
Every other control is a child of the main window, except for the two buttons on the left which are defined as childs of the TabControl it self.
I've subclassed the TC to be able to paint that 50x50 px bitmap in bottom left and I'm handling the WM_PAINT of the subclassed wndproc this way :
case WM_PAINT:
{
if (!BitmapCall) //bool to decide whether I invalidated this rect to print the bitmap or not
CallWindowProc(DefaultTabProc, hwnd, uMsg, wParam, lParam);
if (EncodingTab) //we are in the Encoding tab, so print the bitmap
{
HDC hdc = GetDC(hwnd);
Graphics grap(hdc);
grap.DrawImage(&(*bitmap), 20, 248);
ReleaseDC(hwnd, hdc);
BitmapCall = false;
}
break;
}
Strangely, if I call Graphics grap(GetDC(hwnd)); the problem does not arise, and I'd take this route if it wasn't for the great memory leak i'm facing over few dozens of seconds after the application starts.
I tried to handle Tabcontrol's WM_ERASEBKGND and just return TRUE without luck. I could then make every control child of the TC but apparently groupboxes and radio buttons doesn't like the idea and gets painted all in black leaving me with even more troubles.
Painting the bitmap from the main frame window looks impossible since it gets overpainted by again said TC,
I may finally try to handle the order in which everything gets painted but I have no clue on where to start/how to do
Thanks in advance
I register the window class like this:
WNDCLASSEX wctt;
wctt.cbSize = sizeof(WNDCLASSEX);
wctt.style = CS_DBLCLKS;
wctt.lpfnWndProc = WndProcTooltip;
wctt.cbClsExtra = 0;
wctt.cbWndExtra = 0;
wctt.hInstance = m_hAppInstance;
wctt.hIcon = NULL;
wctt.hCursor = LoadCursor(NULL, IDC_SIZE);
wctt.hbrBackground = NULL;
wctt.lpszMenuName = NULL;
wctt.lpszClassName = _T("myWindow");
wctt.hIconSm = NULL;
RegisterClassEx(&wctt)
As you can see I use wctt.hbrBackground = NULL; so it will have no background.
The window is created like this:
::CreateWindowEx(WS_EX_TOPMOST | WS_EX_TOOLWINDOW,
_T("myWindow"),
NULL,
WS_VISIBLE | WS_POPUP,
50,
50,
150,
100,
NULL,
NULL,
m_hAppInstance,
NULL);
In the paint section I draw icon on the window:
PAINTSTRUCT ps;
HDC hdc;
BITMAP bitmap;
ICONINFO iconinfo;
hdc = ::BeginPaint(hWnd, &ps);
::SetBkMode(hdc,TRANSPARENT);
::GetIconInfo(localIcon, &iconinfo);
::GetObject(iconinfo.hbmColor, sizeof(bitmap), &bitmap);
::DeleteObject(iconinfo.hbmColor);
::DeleteObject(iconinfo.hbmMask);
::DrawIconEx(hdc, 0,0, localIcon, bitmap.bmWidth, bitmap.bmHeight, 0, NULL, DI_NORMAL);
The icon size is smaller than the window size and I get on the background the current view on the window below the popup.
But now when I move the window (or minimize the window below the popup) the background is not changing.
I was trying to make a timer that each time do the flowing:
RECT rcClient;
GetClientRect(hWnd, &rcClient);
InvalidateRect(hWnd,&rcClient,TRUE);
This makes the print function run again but the background of the icon is not changing.
Should I do anything in WM_ERASEBKGND?
Does Anyone have any idea how to make it work?
thanks,
guy
It's not enough to just let the background stay unpainted; you also need to get the window below yours to repaint itself when necessary.
If the windows are part of the same hierarchy, created by the same thread, it is sufficient to give your window the WS_EX_TRANSPARENT extended style. This causes the window underneath to paint itself first so the background is always up-to-date.
Otherwise you need to use SetWindowRgn so that your window actually doesn't exist outside of the borders you wish to paint.
Look at Layered Window. This feature allows creating semi-transparent windows of different shapes.
Add WS_EX_LAYERED extended attribute in your window class.
You can control the transparency of your window with these two functions:
SetLayeredWindowAttributes:
bAlpha controls the opacity of the entire window, if you pass LWA_ALPHA in dwFlags.
When bAlpha is 0, the window is completely transparent. When bAlpha is 255, the window is opaque.
crKey sets the color that would transparent.
All pixels painted by the window in this color will be transparent.
UpdateLayeredWindow gives you precise control over window transparency, you can give different parts of window different levels of transparency.
If you're trying to create a non-rectangular window, this is not sufficient. Setting "no background" simply means the background will not be drawn, and you'll see whatever happens to be in memory at that location.
To create a non-rectangular window, have a look at the SetWindowRgn function.
I am trying to make a radio button control with a transparent background using only Win32 when themes are enabled. The reason for doing this is to allow a radio button to be placed over an image and have the image show (rather than the grey default control background).
What happens out of the box is that the control will have the grey default control background and the standard method of changing this by handling either WM_CTLCOLORSTATIC or WM_CTLCOLORBTN as shown below does not work:
case WM_CTLCOLORSTATIC:
hdcStatic = (HDC)wParam;
SetTextColor(hdcStatic, RGB(0,0,0));
SetBkMode(hdcStatic,TRANSPARENT);
return (LRESULT)GetStockObject(NULL_BRUSH);
break;
My research so far indicates that Owner Draw is the only way to achieve this. I've managed to get most of the way with an Owner Draw radio button - with the code below I have a radio button and a transparent background (the background is set in WM_CTLCOLORBTN). However, the edges of the radio check are cut off using this method - I can get them back by uncommenting the call to the function DrawThemeParentBackgroundEx but this breaks the transparency.
void DrawRadioControl(HWND hwnd, HTHEME hTheme, HDC dc, bool checked, RECT rcItem)
{
if (hTheme)
{
static const int cb_size = 13;
RECT bgRect, textRect;
HFONT font = (HFONT)SendMessageW(hwnd, WM_GETFONT, 0, 0);
WCHAR *text = L"Experiment";
DWORD state = ((checked) ? RBS_CHECKEDNORMAL : RBS_UNCHECKEDNORMAL) | ((bMouseOverButton) ? RBS_HOT : 0);
GetClientRect(hwnd, &bgRect);
GetThemeBackgroundContentRect(hTheme, dc, BP_RADIOBUTTON, state, &bgRect, &textRect);
DWORD dtFlags = DT_VCENTER | DT_SINGLELINE;
if (dtFlags & DT_SINGLELINE) /* Center the checkbox / radio button to the text. */
bgRect.top = bgRect.top + (textRect.bottom - textRect.top - cb_size) / 2;
/* adjust for the check/radio marker */
bgRect.bottom = bgRect.top + cb_size;
bgRect.right = bgRect.left + cb_size;
textRect.left = bgRect.right + 6;
//Uncommenting this line will fix the button corners but breaks transparency
//DrawThemeParentBackgroundEx(hwnd, dc, DTPB_USECTLCOLORSTATIC, NULL);
DrawThemeBackground(hTheme, dc, BP_RADIOBUTTON, state, &bgRect, NULL);
if (text)
{
DrawThemeText(hTheme, dc, BP_RADIOBUTTON, state, text, lstrlenW(text), dtFlags, 0, &textRect);
}
}
else
{
// Code for rendering the radio when themes are not present
}
}
The method above is called from WM_DRAWITEM as shown below:
case WM_DRAWITEM:
{
LPDRAWITEMSTRUCT pDIS = (LPDRAWITEMSTRUCT)lParam;
hTheme = OpenThemeData(hDlg, L"BUTTON");
HDC dc = pDIS->hDC;
wchar_t sCaption[100];
GetWindowText(GetDlgItem(hDlg, pDIS->CtlID), sCaption, 100);
std::wstring staticText(sCaption);
DrawRadioControl(pDIS->hwndItem, hTheme, dc, radio_group.IsButtonChecked(pDIS->CtlID), pDIS->rcItem, staticText);
SetBkMode(dc, TRANSPARENT);
SetTextColor(hdcStatic, RGB(0,0,0));
return TRUE;
}
So my question is two parts I suppose:
Have I missed some other way to achieve my desired result?
Is it possible to fix the clipped button corners issue with my code and still have a transparent background
After looking at this on and off for nearly three months I've finally found a solution that I'm pleased with. What I eventually found was that the radio button edges were for some reason not being drawn by the routine within WM_DRAWITEM but that if I invalidated the radio button control's parent in a rectangle around the control, they appeared.
Since I could not find a single good example of this I'm providing the full code (in my own solution I have encapsulated my owner drawn controls into their own class, so you will need to provide some details such as whether the button is checked or not)
This is the creation of the radiobutton (adding it to the parent window) also setting GWL_UserData and subclassing the radiobutton:
HWND hWndControl = CreateWindow( _T("BUTTON"), caption, WS_CHILD | WS_VISIBLE | BS_OWNERDRAW,
xPos, yPos, width, height, parentHwnd, (HMENU) id, NULL, NULL);
// Using SetWindowLong and GWL_USERDATA I pass in the this reference, allowing my
// window proc toknow about the control state such as if it is selected
SetWindowLong( hWndControl, GWL_USERDATA, (LONG)this);
// And subclass the control - the WndProc is shown later
SetWindowSubclass(hWndControl, OwnerDrawControl::WndProc, 0, 0);
Since it is owner draw we need to handle the WM_DRAWITEM message in the parent window proc.
case WM_DRAWITEM:
{
LPDRAWITEMSTRUCT pDIS = (LPDRAWITEMSTRUCT)lParam;
hTheme = OpenThemeData(hDlg, L"BUTTON");
HDC dc = pDIS->hDC;
wchar_t sCaption[100];
GetWindowText(GetDlgItem(hDlg, pDIS->CtlID), sCaption, 100);
std::wstring staticText(sCaption);
// Controller here passes to a class that holds a map of all controls
// which then passes on to the correct instance of my owner draw class
// which has the drawing code I show below
controller->DrawControl(pDIS->hwndItem, hTheme, dc, pDIS->rcItem,
staticText, pDIS->CtlID, pDIS->itemState, pDIS->itemAction);
SetBkMode(dc, TRANSPARENT);
SetTextColor(hdcStatic, RGB(0,0,0));
CloseThemeData(hTheme);
return TRUE;
}
Here is the DrawControl method - it has access to class level variables to allow state to be managed since with owner draw this is not handled automatically.
void OwnerDrawControl::DrawControl(HWND hwnd, HTHEME hTheme, HDC dc, bool checked, RECT rcItem, std::wstring caption, int ctrlId, UINT item_state, UINT item_action)
{
// Check if we need to draw themed data
if (hTheme)
{
HWND parent = GetParent(hwnd);
static const int cb_size = 13;
RECT bgRect, textRect;
HFONT font = (HFONT)SendMessageW(hwnd, WM_GETFONT, 0, 0);
DWORD state;
// This method handles both radio buttons and checkboxes - the enums here
// are part of my own code, not Windows enums.
// We also have hot tracking - this is shown in the window subclass later
if (Type() == RADIO_BUTTON)
state = ((checked) ? RBS_CHECKEDNORMAL : RBS_UNCHECKEDNORMAL) | ((is_hot_) ? RBS_HOT : 0);
else if (Type() == CHECK_BOX)
state = ((checked) ? CBS_CHECKEDNORMAL : CBS_UNCHECKEDNORMAL) | ((is_hot_) ? RBS_HOT : 0);
GetClientRect(hwnd, &bgRect);
// the theme type is either BP_RADIOBUTTON or BP_CHECKBOX where these are Windows enums
DWORD theme_type = ThemeType();
GetThemeBackgroundContentRect(hTheme, dc, theme_type, state, &bgRect, &textRect);
DWORD dtFlags = DT_VCENTER | DT_SINGLELINE;
if (dtFlags & DT_SINGLELINE) /* Center the checkbox / radio button to the text. */
bgRect.top = bgRect.top + (textRect.bottom - textRect.top - cb_size) / 2;
/* adjust for the check/radio marker */
// The +3 and +6 are a slight fudge to allow the focus rectangle to show correctly
bgRect.bottom = bgRect.top + cb_size;
bgRect.left += 3;
bgRect.right = bgRect.left + cb_size;
textRect.left = bgRect.right + 6;
DrawThemeBackground(hTheme, dc, theme_type, state, &bgRect, NULL);
DrawThemeText(hTheme, dc, theme_type, state, caption.c_str(), lstrlenW(caption.c_str()), dtFlags, 0, &textRect);
// Draw Focus Rectangle - I still don't really like this, it draw on the parent
// mainly to work around the way DrawFocus toggles the focus rect on and off.
// That coupled with some of my other drawing meant this was the only way I found
// to get a reliable focus effect.
BOOL bODAEntire = (item_action & ODA_DRAWENTIRE);
BOOL bIsFocused = (item_state & ODS_FOCUS);
BOOL bDrawFocusRect = !(item_state & ODS_NOFOCUSRECT);
if (bIsFocused && bDrawFocusRect)
{
if ((!bODAEntire))
{
HDC pdc = GetDC(parent);
RECT prc = GetMappedRectanglePos(hwnd, parent);
DrawFocus(pdc, prc);
}
}
}
// This handles drawing when we don't have themes
else
{
TEXTMETRIC tm;
GetTextMetrics(dc, &tm);
RECT rect = { rcItem.left ,
rcItem.top ,
rcItem.left + tm.tmHeight - 1,
rcItem.top + tm.tmHeight - 1};
DWORD state = ((checked) ? DFCS_CHECKED : 0 );
if (Type() == RADIO_BUTTON)
DrawFrameControl(dc, &rect, DFC_BUTTON, DFCS_BUTTONRADIO | state);
else if (Type() == CHECK_BOX)
DrawFrameControl(dc, &rect, DFC_BUTTON, DFCS_BUTTONCHECK | state);
RECT textRect = rcItem;
textRect.left = rcItem.left + 19;
SetTextColor(dc, ::GetSysColor(COLOR_BTNTEXT));
SetBkColor(dc, ::GetSysColor(COLOR_BTNFACE));
DrawText(dc, caption.c_str(), -1, &textRect, DT_WORDBREAK | DT_TOP);
}
}
Next is the window proc that is used to subclass the radio button control - this
is called with all windows messages and handles several before then passing unhandled
ones on to the default proc.
LRESULT OwnerDrawControl::WndProc(HWND hWnd, UINT uMsg, WPARAM wParam,
LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData)
{
// Get the button parent window
HWND parent = GetParent(hWnd);
// The page controller and the OwnerDrawControl hold some information we need to draw
// correctly, such as if the control is already set hot.
st_mini::IPageController * controller = GetWinLong<st_mini::IPageController *> (parent);
// Get the control
OwnerDrawControl *ctrl = (OwnerDrawControl*)GetWindowLong(hWnd, GWL_USERDATA);
switch (uMsg)
{
case WM_LBUTTONDOWN:
if (controller)
{
int ctrlId = GetDlgCtrlID(hWnd);
// OnCommand is where the logic for things like selecting a radiobutton
// and deselecting the rest of the group lives.
// We also call our Invalidate method there, which redraws the radio when
// it is selected. The Invalidate method will be shown last.
controller->OnCommand(parent, ctrlId, 0);
return (0);
}
break;
case WM_LBUTTONDBLCLK:
// We just treat doubleclicks as clicks
PostMessage(hWnd, WM_LBUTTONDOWN, wParam, lParam);
break;
case WM_MOUSEMOVE:
{
if (controller)
{
// This is our hot tracking allowing us to paint the control
// correctly when the mouse is over it - it sets flags that get
// used by the above DrawControl method
if(!ctrl->IsHot())
{
ctrl->SetHot(true);
// We invalidate to repaint
ctrl->InvalidateControl();
// Track the mouse event - without this the mouse leave message is not sent
TRACKMOUSEEVENT tme;
tme.cbSize = sizeof(TRACKMOUSEEVENT);
tme.dwFlags = TME_LEAVE;
tme.hwndTrack = hWnd;
TrackMouseEvent(&tme);
}
}
return (0);
}
break;
case WM_MOUSELEAVE:
{
if (controller)
{
// Turn off the hot display on the radio
if(ctrl->IsHot())
{
ctrl->SetHot(false);
ctrl->InvalidateControl();
}
}
return (0);
}
case WM_SETFOCUS:
{
ctrl->InvalidateControl();
}
case WM_KILLFOCUS:
{
RECT rcItem;
GetClientRect(hWnd, &rcItem);
HDC dc = GetDC(parent);
RECT prc = GetMappedRectanglePos(hWnd, parent);
DrawFocus(dc, prc);
return (0);
}
case WM_ERASEBKGND:
return 1;
}
// Any messages we don't process must be passed onto the original window function
return DefSubclassProc(hWnd, uMsg, wParam, lParam);
}
Finally the last little piece of the puzzle is that you need to invalidate the control (redraw it) at the right times. I eventually found that invalidating the parent allowed the drawing to work 100% correctly. This was causing flicker until I realised that I could get away by only invalidating a rectangle as big as the radio check, rather than as big as the whole control including text as I had been.
void InvalidateControl()
{
// GetMappedRectanglePos is my own helper that uses MapWindowPoints
// to take a child control and map it to its parent
RECT rc = GetMappedRectanglePos(ctrl_, parent_);
// This was my first go, that caused flicker
// InvalidateRect(parent_, &rc_, FALSE);
// Now I invalidate a smaller rectangle
rc.right = rc.left + 13;
InvalidateRect(parent_, &rc, FALSE);
}
A lot of code and effort for something that should be simple - drawing a themed radio button over a background image. Hopefully the answer will save someone else some pain!
* One big caveat with this is it only works 100% correctly for owner controls that are over a background (such as a fill rectangle or an image). That is ok though, since it is only needed when drawing the radio control over a background.
I've done this some time ago as well. I remember the key was to just create the (radio) buttons as usual. The parent must be the dialog or window, not a tab control. You could do it differently but I created a memory dc (m_mdc) for the dialog and painted the background on that. Then add the OnCtlColorStatic and OnCtlColorBtn for your dialog:
virtual HBRUSH OnCtlColorStatic(HDC hDC, HWND hWnd)
{
RECT rc;
GetRelativeClientRect(hWnd, m_hWnd, &rc);
BitBlt(hDC, 0, 0, rc.right - rc.left, rc.bottom - rc.top, m_mdc, rc.left, rc.top, SRCCOPY);
SetBkColor(hDC, GetSysColor(COLOR_BTNFACE));
if (IsAppThemed())
SetBkMode(hDC, TRANSPARENT);
return (HBRUSH)GetStockObject(NULL_BRUSH);
}
virtual HBRUSH OnCtlColorBtn(HDC hDC, HWND hWnd)
{
return OnCtlColorStatic(hDC, hWnd);
}
The code uses some in-house classes and functions similar to MFC, but I think you should get the idea. As you can see it draws the background of these controls from the memory dc, that's key.
Give this a try and see if it works!
EDIT: If you add a tab control to the dialog and put the controls on the tab (that was the case in my app) you must capture it's background and copy it to the memory dc of the dialog. It's a bit of an ugly hack but it works, even if the machine is running some extravagant theme that uses a gradient tab background:
// calculate tab dispay area
RECT rc;
GetClientRect(m_tabControl, &rc);
m_tabControl.AdjustRect(false, &rc);
RECT rc2;
GetRelativeClientRect(m_tabControl, m_hWnd, &rc2);
rc.left += rc2.left;
rc.right += rc2.left;
rc.top += rc2.top;
rc.bottom += rc2.top;
// copy that area to background
HRGN hRgn = CreateRectRgnIndirect(&rc);
GetRelativeClientRect(m_hWnd, m_tabControl, &rc);
SetWindowOrgEx(m_mdc, rc.left, rc.top, NULL);
SelectClipRgn(m_mdc, hRgn);
SendMessage(m_tabControl, WM_PRINTCLIENT, (WPARAM)(HDC)m_mdc, PRF_CLIENT);
SelectClipRgn(m_mdc, NULL);
SetWindowOrgEx(m_mdc, 0, 0, NULL);
DeleteObject(hRgn);
Another interesting point, while we're busy now, to get it all non-flickering create the parent and children (buttons, statics, tabs etc) with the WS_CLIPCHILDREN and WS_CLIPSIBLINGS style. The the order of creation is essential: First create the controls you put on the tabs, then create the tab control. Not the other way around (although it feels more intuitive). That because the tab control should clip the area obscured by the controls on it :)
I can't immediately try this out, but so far as I recall, you don't need owner draw. You need to do this:
Return 1 from WM_ERASEBKGND.
Call DrawThemeParentBackground from WM_CTLCOLORSTATIC to draw the background there.
Return GetStockObject(NULL_BRUSH) from WM_CTLCOLORSTATIC.
Knowing the sizes and coordinates radio button, we will copy the
image to them closed.
Then we create a brush by means of
BS_PATTERN style CreateBrushIndirect
Farther according to the
usual scheme - we return handle to this brush in reply to COLOR -
the message (WM_CTLCOLORSTATIC).
I have no idea why you are doing it so difficult, this is best solved via CustomDrawing
This is my MFC Handler to draw a Notebook on a CTabCtrl control. I'm not really sure why i need to Inflate the Rectangle, because if i don't do it a black border is drawn.
And another conceptional bug MS made is IMHO that i have to overwrite the PreErase drawing phase instead of the PostErase. But if i do the later the checkbox is gone.
afx_msg void AguiRadioButton::OnCustomDraw(NMHDR* notify, LRESULT* res) {
NMCUSTOMDRAW* cd = (NMCUSTOMDRAW*)notify;
if (cd->dwDrawStage == CDDS_PREERASE) {
HTHEME theme = OpenThemeData(m_hWnd, L"Button");
CRect r = cd->rc; r.InflateRect(1,1,1,1);
DrawThemeBackground(theme, cd->hdc, TABP_BODY, 0, &r,NULL);
CloseThemeData(theme);
*res = 0;
}
*res = 0;
}