I'm trying to understand the behaviour of a Windows toolbar - in particular how the following values interact:
the size of the bitmap image used
the effective size of a toolbar button
the padding between the image and the button edge
the height of the toolbar
Text displayed by a button is not relevant in my case.
What I actually want to do is provide an option for the user so he can choose from several toolbar button sizes (that will display bitmaps of say, 16x16, 32x32, or 48x48 pixels) and redisplay the toolbar accordingly after the option value changes. This is implemented by destroying the toolbar's image lists and rebuilding them with the appropriate bitmaps. The problem I currently have is that when switching from size 16 to 48 and back to size 16, the toolbar looks slightly different than before.
This is what the toolbar looks like when the application starts (correct):
Once I switch to size 48 and back again, it looks like this (wrong):
All buttons are higher than before, and each dropdown button has additional space around its bitmap and its dropdown arrow.
(For testing purposes, the toolbar has been made high enough to accomodate all button sizes without requiring an increase in height. This is to rule out the possibility that the change in button size stems from a possible toolbar resize, necessitated by temporarily switching to size 48.)
It looks as if additional padding were being rendered between a button bitmap and the button edge - as if rebuilding the toolbar with larger bitmaps/buttons caused Windows to internally increase the padding (which would make sense), but not decrease it when I subsequently rebuild the toolbar with the smaller bitmaps/buttons. However, sending TB_GETPADDING always returns 0x00060007, which indicates that the standard (correct) padding for 16x16 bitmaps is in place.
In an attempt to solve the problem by setting padding myself, I set the TBSTYLE_AUTOSIZE style on all non-separator buttons (this is required in order to apply padding). With this style, without even calling TB_SETPADDING, after switching to size 48 and back again, the toolbar looks like this:
In this case, the button height is also wrong.
The question is: What is causing the buttons to be displayed differently after rebuilding the image lists?
Some aside notes:
When building the toolbar, I call TB_SETBITMAPSIZE, but neither TB_SETBUTTONSIZE nor TB_SETPADDING, because the bitmap size is all I have, and I assumed the button size would be derived correctly from that.
I'm aware I could simply build the entire toolbar window from scratch (not just the image lists), but would like to avoid that, so I can keep working with the same toolbar window handle.
I'm aware of the CCS_NORESIZE toolbar style (it's currently set) and the TB_AUTOSIZE message, but experiments with them have not led to any insights.
I can't say what is the problem(there is no code in the question) but it is most probable
that the solution of destroying the list of images causes this. You dont need to destroy the lists
but to remove the buttons and then add new ones. The bellow code works fine:
Create ToolBar:
if((toolBarHwnd = CreateWindowEx(
0,
TOOLBARCLASSNAME,,
NULL,
WS_VISIBLE | WS_CHILD | TBSTYLE_WRAPABLE,
0,
0, //820,
0,
0,
winHwnd, //main window
(HMENU)IDC_TOOLBAR,
hThisInstance,
NULL
)) == NULL){/*Error*/}
Create ImageList's for your images:
HIMAGELIST g_hImageListSmall = NULL, g_hImageListMedium = NULL, g_hImageListLarge = NULL;
int numButtons = 3
g_hImageListSmall = ImageList_Create(16, 16, // Dimensions of individual bitmaps.
ILC_COLOR16 | ILC_MASK, // Ensures transparent background.
numButtons, 0);
g_hImageListMedium = ImageList_Create(32, 32,
ILC_COLOR16 | ILC_MASK,
numButtons, 0);
g_hImageListLarge = ImageList_Create(48, 48,
ILC_COLOR16 | ILC_MASK,
numButtons, 0);
Add images to the lists:
HBITMAP hBitmapImageSmall = NULL, hBitmapImageMedium = NULL, hBitmapImageLarge = NULL;
hBitmapImageSmall = LoadImage(NULL, L"....YourBitmap.bmp", IMAGE_BITMAP, 16, 16, 0x10);
ImageList_Add(g_hImageListSmall , hBitmapImageSmall, NULL);
ImageList_Add(g_hImageListSmall , hBitmapImageSmall, NULL);
ImageList_Add(g_hImageListSmall , hBitmapImageSmall, NULL); //I am using the same image
hBitmapImageMedium = LoadImage(NULL, L"....YourBitmap.bmp", IMAGE_BITMAP, 32, 32, 0x10);
ImageList_Add(g_hImageListSmall , hBitmapImageMedium , NULL);
ImageList_Add(g_hImageListSmall , hBitmapImageMedium , NULL);
ImageList_Add(g_hImageListSmall , hBitmapImageMedium , NULL);
The same with the large one(48x48)
Add g_hImageListSmall to the ToolBar for start:
//Set the image list.
SendMessage(toolBarHwnd, TB_SETIMAGELIST, (WPARAM)0, (LPARAM)g_hImageListSmall);
// Initialize button info.
// IDM_NEW, IDM_OPEN, and IDM_SAVE are application-defined command constants.
TBBUTTON tbButtons[numButtons] =
{
{ 0, IDM_NEW, TBSTATE_ENABLED, BTNS_AUTOSIZE, {0}, 0, (INT_PTR)NULL },
{ 1, IDM_OPEN, TBSTATE_ENABLED, BTNS_AUTOSIZE, {0}, 0, (INT_PTR)NULL},
{ 2, IDM_SAVE, TBSTATE_ENABLED, BTNS_AUTOSIZE, {0}, 0, (INT_PTR)NULL}
};
// Add buttons.
SendMessage(toolBarHwnd, TB_BUTTONSTRUCTSIZE, (WPARAM)sizeof(TBBUTTON), 0);
SendMessage(toolBarHwnd, TB_ADDBUTTONS, (WPARAM)numButtons, (LPARAM)&tbButtons);
// Resize the toolbar
SendMessage(toolBarHwnd, TB_AUTOSIZE, 0, 0);
That is the first step.
Write two functions:
void RemoveButtons(void){
int nCount, i;
// Remove all of the existing buttons, starting with the last one.
nCount = SendMessage(toolBarHwnd, TB_BUTTONCOUNT, 0, 0);
for(i = nCount - 1; i >= 0; i--){ SendMessage(toolBarHwnd, TB_DELETEBUTTON, i, 0); }
return;
}
enum{SMALL, MEDIUM, LARGE};
void AddButtons(int sizeButtons){
if(sizeButtons == SMALL){
SendMessage(toolBarHwnd, TB_SETIMAGELIST, (WPARAM)0, (LPARAM)g_hImageListSmall);
}
else if(sizeButtons == MEDIUM){
SendMessage(toolBarHwnd, TB_SETIMAGELIST, (WPARAM)0, (LPARAM)g_hImageListMedium);
}
else{
SendMessage(toolBarHwnd, TB_SETIMAGELIST, (WPARAM)0, (LPARAM)g_hImageListLarge);
}
// Add buttons.
SendMessage(toolBarHwnd, TB_BUTTONSTRUCTSIZE, (WPARAM)sizeof(TBBUTTON), 0);
SendMessage(toolBarHwnd, TB_ADDBUTTONS, (WPARAM)numButtons, (LPARAM)&tbButtons);
// Resize the toolbar
SendMessage(toolBarHwnd, TB_AUTOSIZE, 0, 0);
return;
}
When ever you want to change the size of the buttons in ToolBar:
RemoveButtons();
AddButtons(LARGE); //or SMALL, MEDIUM
References:
How to Create Toolbars
How to Customize Toolbars
The common controls have been a major bug factory in Windows. Microsoft has had a great deal of trouble keeping them compatible across 6 major Windows releases and 10 versions of comctl32.dll. Particularly the visual style renderers have been a problem spot.
Core issue is that the api for them was set in stone 18 years ago with no reasonable way to make it work differently from the way it worked in their first release. Their code acquired a great many deal of appcompat hacks to achieve this. Such an hack will for example doctor a value that was returned by the previous version so that the client program has no idea, and doesn't need to know, that it is working with a very different version from the one it was tested against.
This has side-effects, the kind you'll discover when you use the controls in an unusual way that's very different from the way they are normally used by meat-and-potatoes Windows programs. Exactly like your scenario. Very high odds that you are battling internal state of the toolbar that you cannot see and doesn't get properly restored when you switch sizes. Quite undebuggable, that internal state isn't visible at all. Other than from the undesirable side-effects.
The solution is the one you already know. Recreate the toolbar from scratch. It can't go wrong that way.
Related
Playing around with the console functions to control the layout of a console program, and I cannot change its size.
Currently, what I can do is disable resizing, remove buttons and change the buffer size, but if I try to resize the window itself, all attempts fail; albeit, some functions do resize the window, but in pixels, so scale is drastically off.
What I've done so far (not a C++ person, just fiddling around, go easy on syntax-isms):
#include <iostream>
#include <Windows.h>
using namespace std;
COORD conBufferSize = { 150, 40 };
SMALL_RECT conScreen = { 0, 0, 150, 40 };
CONSOLE_SCREEN_BUFFER_INFOEX csbie;
int main()
{
// console opened for application
HWND hwConsole = GetConsoleWindow();
// hide it
ShowWindow(hwConsole, SW_HIDE);
// get the style for it
DWORD style = GetWindowLong(hwConsole, GWL_STYLE);
// disable maximizing and minimizing and resizing
style &= ~(WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SIZEBOX);
SetWindowLong(hwConsole, GWL_STYLE, style);
HANDLE hConsole = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0, NULL, CONSOLE_TEXTMODE_BUFFER, NULL);
SetConsoleScreenBufferSize(hConsole, conBufferSize);
// this does nothing to the window itself as best I can tell
// if by "window" it means what portion of the display window you view "into"
// commented out here for functionality
// SetConsoleWindowInfo(hConsole, TRUE, &conScreen);
SetConsoleActiveScreenBuffer(hConsole);
// this sequence works, but seems by accident
// surely there is another method?
csbie.cbSize = sizeof(csbie);
GetConsoleScreenBufferInfoEx(hConsole, &csbie);
csbie.srWindow = conScreen;
SetConsoleScreenBufferInfoEx(hConsole, &csbie);
// required to update styles
// using the cx/cy parameters sets size in pixels
// that is much smaller than buffer size which accounts for font size
// therefore this "doesn't" work
SetWindowPos(hwConsole, HWND_TOP, 0, 0, 0, 0, SWP_FRAMECHANGED | SWP_NOMOVE | SWP_NOSIZE| SWP_SHOWWINDOW);
// to look at the console until close
while (1) {
}
return 0;
}
Now from what I can reason, if I have a screen buffer that is 100 columns by 40 rows, that doesn't translate directly to the size of the window housing the buffer. So my next thought is that I need to determine how many pixels the current console font is using, then multiply the buffer dimensions by that to determine the pixel size and use SetWindowPos or the SetConsoleScreenBufferInfoEx methods.
One thing I am unsure about is why the srWindow attribute is able to modify the display window with a similar description to that of SetConsoleWindowInfo and yet that produces no discernable change.
One thing I am unsure about is why the srWindow attribute is able to
modify the display window with a similar description to that of
SetConsoleWindowInfo and yet that produces no discernable change.
According to the doc,
The function fails if the specified window rectangle extends beyond
the boundaries of the console screen buffer. This means that the Top
and Left members of the lpConsoleWindow rectangle (or the calculated
top and left coordinates, if bAbsolute is FALSE) cannot be less than
zero. Similarly, the Bottom and Right members (or the calculated
bottom and right coordinates) cannot be greater than (screen buffer
height – 1) and (screen buffer width – 1), respectively. The function
also fails if the Right member (or calculated right coordinate) is
less than or equal to the Left member (or calculated left coordinate)
or if the Bottom member (or calculated bottom coordinate) is less than
or equal to the Top member (or calculated top coordinate).
Use GetConsoleScreenBufferInfoEx to get the size of the screen buffer (e.p: 120,30). As long as the SMALL_RECT set is less than 120, 30, you will see the screen buffer size change after calling SetConsoleActiveScreenBuffer.
SMALL_RECT conScreen = { 0, 0, 50, 20 };
...
SetConsoleWindowInfo(hConsole, TRUE, &conScreen);
SetConsoleActiveScreenBuffer(hConsole);
Please always check the return value of each api when debugging.
I've followed Microsoft's tutorial on creating a Device Context, and I've tried looking around the internet for a decent source (apparently, MFC is a mystical thing). The following successfully prints out "Hello, World!"; except it's extremely tiny.
How can I send a CImage to the printer, rather than text?
And how could I get the text's size to be bigger than a couple millimeters?
I've scoured MSDN, but everything is either outdated (like the example code I am using), or just not well documented.
// get the default printer
CPrintDialog dlg(FALSE);
dlg.GetDefaults();
// is a default printer set up?
HDC hdcPrinter = dlg.GetPrinterDC();
if (hdcPrinter == NULL)
{
//MessageBox(_T("Buy a printer!"));
}
else
{
// create a CDC and attach it to the default printer
CDC dcPrinter;
dcPrinter.Attach(hdcPrinter);
// call StartDoc() to begin printing
DOCINFO docinfo;
memset(&docinfo, 0, sizeof(docinfo));
docinfo.cbSize = sizeof(docinfo);
docinfo.lpszDocName = _T("CDC::StartDoc() Code Fragment");
// if it fails, complain and exit gracefully
if (dcPrinter.StartDoc(&docinfo) < 0)
{
//MessageBox(_T("Printer wouldn't initalize"));
}
else
{
// start a page
if (dcPrinter.StartPage() < 0)
{
//MessageBox(_T("Could not start page"));
dcPrinter.AbortDoc();
}
else
{
// actually do some printing
//CGdiObject* pOldFont = dcPrinter.SelectStockObject(SYSTEM_FONT);
dcPrinter.SetMapMode(MM_HIENGLISH);
auto font = CreateFont(
3'000, // nHeight
1'500, // nWidth
0, // nEscapement
0, // nOrientation
FW_NORMAL, // nWeight
FALSE, // bItalic
FALSE, // bUnderline
0, // cStrikeOut
ANSI_CHARSET, // nCharSet
OUT_DEFAULT_PRECIS, // nOutPrecision
CLIP_DEFAULT_PRECIS, // nClipPrecision
DEFAULT_QUALITY, // nQuality
DEFAULT_PITCH | FF_SWISS, // nPitchAndFamily
_T("Arial")); // lpszFacename
dcPrinter.SelectObject(&font);
dcPrinter.TextOut(450, 450, _T("Hello World!"), 12);
dcPrinter.EndPage();
dcPrinter.EndDoc();
//dcPrinter.SelectObject(pOldFont);
}
}
}
Tiny Text Problem
The problem is that, by default, the size of a font is specified in device-dependent units and printers are generally much higher resolution that a screen. So if you've created a font that is 20 pixels high on the screen (which might have 96 pixels per inch) when you try to use that font on a printer, which maybe has 300 or 600 dots per inch, your text looks really small.
As another answer shows, one idea is to change the mapping mode so that the printer uses units that are closer to what is on the screen.
An alternative way is to create a new font with an appropriate size (the lfHeight field in the LOGFONT structure) based on the DPI of the printer, which you can determine with the GetDeviceCaps function. This can be handy if you want a particular font size, like 14 point text.
LOGFONT lf = {0};
lf.lfHeight = -MulDiv(point_size, ::GetDeviceCaps(dcPrinter, LOGPIXELSY), 72);
// init other field of lf as you like
HFONT hfontPrinter = ::CreateFontIndirect(&lf);
HFONT hfontOld = ::SelectObject(hdcPrinter, hfontPrinter);
// now draw to the hdcPrinter
::SelectObject(hdcPrinter, hfontOld);
::DeleteObject(hfontPrinter);
Sending a CImage
I don't use MFC, but it looks like you can just call CImage::StretchBlt with the printer DC. Once again, you'll probably have to take the printer's much higher resolution into account when you choose the target coordinates.
Use CFont::CreatePointFont() or CFont::CreatePointFontIndirect() to create a font that is reasonable. Most printers are 600 DPI. Most screens are 96 DPI. A 12 point font on the screen is basically a 2 point font and illegible on a printer.
Create the font and select it into your DC. Do not forget to select it out of the DC after using it and before destroying your DC (CDC class). (The CDC destructor automatically deletes the HDC).
Here is the problem:
dcPrinter.SetMapMode(MM_TEXT);
MM_TEXT maps one logical point to one device point; considering typical resolution of 600 DPI for a printer, your stuff will be few times smaller that on the screen.
Use MM_HIENGLISH or some other device-independent mode; here is MSDN link.
I have used the following to successfully print "Hello World!" and "Have a Nice Day!" to the right of a 200x200 monochrome bitmap (MyLogo.bmp) placed at the origin of the printer page (I am using a black & white thermal printer):
CDC printDC( GetMyPrintDC() ); // e.g. as per original code
DOCINFO di( GetMyDocInfo() ); // e.g. as per original code
printDC.StartDoc( &di );
ATL::CImage logo;
logo.Load( "MyLogo.bmp" );
const BOOL result( logo.Draw( printDC.GetSafeHdc(), CPoint( 0, 0 ) ) );
CFont myFont, *old;
myFont.CreatePointFont(100, "Courier New", &printDC);
old = printDC.SelectObject(&myFont);
printDC.TextOut( 250, 50, " Hello World!" );
printDC.TextOut( 250, 150, "Have a nice Day!" );
printDC.SelectObject( old );
myFont.DeleteObject();
printDC.EndPage();
printDC.EndDoc();
printDC.DeleteDC();
The three indented lines highlight all that is required to render a CImage on my printer. Vary the parameter in CreatePointFont() to size the (otherwise tiny) text to suit.
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.
I have a standard MFC SDI app. In the About Dialog (created with the MFC Wizard), I am trying to change some static text format (labels). This is my code:
BOOL CAboutDlg::OnInitDialog()
{
CDialogEx::OnInitDialog();
auto font_programname = std::make_shared<CFont>();
font_programname->CreateFontW(25, 0, 0, 0, FW_BLACK, 0, 1, 0, 0, 0, 0, 0, 0, _T("Arial"));
_label_programname.SetFont(font_programname.get());
return TRUE; // return TRUE unless you set the focus to a control
// EXCEPTION: OCX Property Pages should return FALSE
}
However, this results only in the font becoming bold, but the size does not change. What am I doing wrong?
The font is becoming bolder, so the CreateFont and SetFont are doing something. This leaves the Font Mapper as the next suspect. The "Arial" is a suggestion, but the font mapper will look at other characteristics first. The font you are seeing is most likely the largest raster (non True Type) font that is available in an FW_BLACK weight. Getting the exact font you want will require filling in other parameters of CreateFont so the desired font is located.
For debugging, follow the CreateFont call with a call to GetLogFont and view the data structure to see what font was actually mapped.
The comment above concerning the lifetime of the font is correct. That may not be the first issue you are facing but it is an issue. The CFont needs to be a dialog-class variable, not a local variable in the function, so the font object lasts as long as the control on the dialog.
It does look like you do not need a CFont object for your purposes, as you let it go out of scope.
Also see WM_SETFONT.
const int iFontSize = 25;
const CString sFont = L"Arial";
HFONT hFont = CreateFontW(iFontSize, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, sFont);
yourControl.SendMessageW(WM_SETFONT, reinterpret_cast<WPARAM>(hFont), TRUE);
The low-order word of lParam specifies whether the control should be redrawn immediately upon setting the font. If this parameter is TRUE, the control redraws itself.
Though you should keep the object(s) in a container too, (E.g. std::vector<HFONT>) and delete the/all object(s) later (destructor).
The application should call the DeleteObject function to delete the font when it is no longer needed; for example, after it destroys the control.
This is hopefully simple: I have an application which uses CListCtr in report mode and I want to assign icons to the entries. The icons should be simple square uniformly coloured icons 16x16.
I know ( - I think I know - ) how to handle CListCtr and CImageList, but the challenge I have is the following:
The icon colour is created by the code and arbitrary COLORREF
The icons are not created as files in my resources but should be created by code also. If need be, there can be one 'template' icon in which a specific color is replaced by COLORREF from above.
Essentially, I want to 'abuse' the images as kind of status-light in my CListCtr but with arbitrary colour.
Can anybody give me a short example code snipped for:
Creating a HICON element which is a 16x16 uniformly filled bitmap of COLORREF specified colour?
Try something like this:
CDC dc;
dc.CreateCompatibleDC(NULL);
m_bitmap.CreateBitmap(16, 16, dc.GetDeviceCaps(PLANES), dc.GetDeviceCaps(BITSPIXEL), NULL);
m_imageList.Create(16, 16, ILC_COLORDDB, 0, 1);
HGDIOBJ hOld = dc.SelectObject(m_bitmap);
dc.FillSolidRect(0, 0, 16, 16, RGB(0xff, 0, 0));
dc.SelectObject(hOld);
m_imageList.Add(&m_bitmap, RGB(0, 0, 0));
m_listCtrl.SetImageList(&m_imageList, LVSIL_SMALL);
m_listCtrl.InsertItem(0, _T("hello"), 0);
Slight modification to the accepted answer from mockfrog above.
This also uses the trick I've learnt of here: Using CImageList to convert from HBITMAP to HICON.
Note that it's important to use ILC_COLOR32 to get the full range of colours and not some unwanted colour casting.
HICON CCMixTP_Dialog::CreateColorIcon2( COLORREF color )
{
CDC dc;
dc.CreateCompatibleDC(NULL);
CBitmap bitmap;
bitmap.CreateBitmap(16, 16, dc.GetDeviceCaps(PLANES), \
dc.GetDeviceCaps(BITSPIXEL), NULL);
CImageList convertBuffer;
convertBuffer.Create(16, 16, ILC_COLOR32, 1, 1);
HGDIOBJ hOld = dc.SelectObject(bitmap);
dc.FillSolidRect(0, 0, 16, 16, color);
dc.SelectObject(hOld);
convertBuffer.Add( &bitmap, RGB(0,0,0) ); // Mask black pixels as black.
return convertBuffer.ExtractIcon(0);
}
My advise is not to create icons in this way.
Just use NM_CUSTOMDRAW to draw the element by yourself. You find a great explanation here in this two articles. With this code it is simple to draw the specified area in the color you want!
Article1 Article2
Creating an icon is possible with CreateIconIndirect. You just need to create 2 bitmaps. The drawback here is you need to destroy all theicons you create.
h