Themed menu’s icons, a complete Vista and XP solution (updated)
Update: Steve King has patched my Vista GDI+ based menus with pure GDI method at TortoiseSVN revision 14191 as described lately by Microsoft. Pure GDI method no longer requires GDI+, which is not present in Premium versions of Vista, maintaining full compatibility with older versions of Windows.
I’m an author of few patches for both Tortoise SVN and Tortoise CVS that makes them display the explorer’s context menu icons nicely on XP and Windows 2000. Both programs are implementing IContextMenu and using QueryContextMenu function to create items of popup menu of explorer. Briefly the called extension must fill menu items with InsertMenuItem using suplied HMENU hmenu parameter.
During development of those few patches I’ve learnt some few new things about way we make icons displayed next to menu items I want to share with you…
How to get icons in context menus
Methods described here are related to shell context menu extension, however they can be used in any Windows application.
Initially both Tortoises were filling hbmpUnchecked & hbmpChecked fields of MENUITEMINFO that is passed to InsertMenuItem with HBITMAP created from icon to get icons on menu item. This solution works on all Windows since 95. However the strong limitation is that HBITMAP must be SM_CXMENUCHECK x SM_CYMENUCHECK (usually 12 x 12). So if you are using 16 x 16 icon, the icon gets squished and looks awfully. The function used to convert icon to bitmap is:
Tortoise SVN was using also owner draw method. I won’t describe here details of this method. This relays on MENUITEMINFO fType flag set to MFT_OWNERDRAW. Shell extension in HandleMenuMsg2 callback should handle WM_MEASUREITEM and WM_DRAWITEM. This method is generally OK, however it has several flaws:
- We need to measure & draw menu in all stated ourselves, which makes us write plenty of code.
- Ownerdraw menus are not respecting visual styles of Windows XP or Vista. We would need to use uxtheme functions to somehow handle rendering of menu parts on those systems.
- We need to keep exta context information for each menu item with text, icon handle, etc.
- Keyboard shortcuts doesn’t work automatically, we must handle WM_MENUCHAR to make them work.
Since Windows 98 MENUITEMINFO has extra field hbmpItem. This field can be used for setting the HBITMAP with bitmap that is displayed next to the menu item. hbmpItem can be set also to HBMMENU_CALLBACK which will make menu item work like owner-draw, but WM_MEASUREITEM & WM_DRAWITEM just need to handle icon drawing, rest will be done by Windows. This method is easiest to implement and so it is used inside many application, I just name on I use or develop: wxWidgets SDK, Miranda IM. We just need to initialize menu item like that:
MENUITEMINFO menuiteminfo; sizeof(menuiteminfo); menuiteminfo.fMask = MIIM_FTYPE | MIIM_ID | MIIM_SUBMENU | MIIM_DATA | MIIM_BITMAP | MIIM_STRING; menuiteminfo.fType = MFT_STRING; menuiteminfo.dwTypeData = lpszMenuTitle; menuiteminfo.cch = _tcslen(lpszMenuTitle); menuiteminfo.hbmpItem = HBMMENU_CALLBACK; menuiteminfo.wID = id; menuiteminfo.cbSize =
Rest is done in WM_MEASUREITEM where we need to just make sure we have space for 16 x 16 image using:
case WM_MEASUREITEM: break;
Then to draw an icon we need to handle WM_DRAWITEM, but just drawing the icon, nothing else:
case WM_DRAWITEM: break;
Simple ? Yes it is. However there are some issues with this method as well:
- When this method is used on Windows 2000 shell extension window background popup menu, then shell.dll is removing text from the menu, so we see just icons.This is obviously a bug of Windows 2000 shell.dll, because MSDN documentation states this shall work regardless of the sittuation, but we need to somehow get over it. Surprisingly it does work fine when we right-click on explorer item (file or folder). The easiest solution is using hbmp(Un)checked method when uFlags == 0 of QueryContextMenu, which indicated we clicked the background, so we fall back to most primitive method, but at least we got text and “some” icons in the menu.Note: This bug only appears in Windows 2000 explorer’s background menu of shell extension, so in every other situation as standalone program menus HBMMENU_CALLBACK method can be used without any problem. So you may not care about it unless you are shell extension developer.
- Vista is removing menu theme when some menu item has hbmpItem set to HBMMENU_CALLBACK, so we will have nice icons and nice menu, but if we want to have nice icons with 100% themed menu on Vista we need to use last method…
Vista PARGB32 hbmpItem bitmap method (Updated)
Vista strongly relays on 32-bit pre-multiplied alpha RGB bitmaps for rendering its interface. In Vista hbmpItem can be set to PARGB32 HBITMAP and this bitmap will be nicely displayed by Vista together with theming as you can see on the screenshot at right. I got know of this possibility reading nice article Vista Style Menus, Part 1 – Adding icons to standard menus at ShellRevealed blog.
The most important question is how to we get our icon (regardless it is 32-bit with alpha, or 256-color with mask) converted to PARGB32 HBITMAP. Windows API doesn’t give such possibility straight of the box. Article from ShellRevealed proposes WIC (Windows Imaging Component) which is cool & quite simple for conversion or Vista‘s GDI method, but those require Vista SDK, which may be annoying for those using Visual Studio‘s out of the box.
As an alternative to that I’ve used Gdiplus which is present on most of the systems since Windows 2000, and most shipped with Visual Studios Platforms SDKs. This method is also much simpler than WIC or GDI method from described article.
Alternative solution to WIC is to use pure Vista GDI (UxTheme) calls as described at http://msdn.microsoft.com/en-us/library/bb757020.aspx?s=6 (GDI_CVistaMenuApp.cpp sample). It was implemented in TortoiseSVN revision 14191 by Steve King. It uses BeginBufferedPaint, EndBufferedPaint and GetBufferedPaintBits dynamically loaded from Vista‘s UXTHEME.DLL and Create32BitHBITMAP and ConvertBufferToPARGB32 from GDI_CVistaMenuApp.cpp sample.
The PARGB32 function is as follows:
So in this case instead menuiteminfo.hbmpItem = HBMMENU_CALLBACK we do menuiteminfo.hbmpItem = IconToBitmapPARGB32(lpszIconResourceID). We shouldn’t forget of initializing Gdiplus library with GdiplusStartup(&m_gdipToken, &gdiplusStartupInput, NULL) in program/DLL initialization code and shutting it down after all with GdiplusShutdown(m_gdipToken).
If we want to be compatible with older Windows versions, we shall load (map) the Vista‘s UXTHEME.DLL functions dynamically only on Vista:
typedef DWORD ARGB; typedef typedef typedef /* (...) */ HMODULE hUxTheme = ::GetModuleHandle (_T("UXTHEME.DLL")); pfnGetBufferedPaintBits = (FN_GetBufferedPaintBits)::GetProcAddress(hUxTheme, "GetBufferedPaintBits"); pfnBeginBufferedPaint = (FN_BeginBufferedPaint)::GetProcAddress(hUxTheme, "BeginBufferedPaint"); pfnEndBufferedPaint = (FN_EndBufferedPaint)::GetProcAddress(hUxTheme, "EndBufferedPaint");
Since we are going to use Gdiplus only on Vista, we may use Gdiplus.dll as delayed load DLL, so it won’t be loaded on older systems using previous methods, saving us some memory. Simple enough ?
Testing Windows version number with GetVersionEx and combining this method for Vista with HBMENU_CALLBACK method for Windows XP and older systems (with hbmp(Un)checked fallback on explorer extension on Windows 2000 if needed) is my opinion best method of having nice menus in all modern Windows systems. This is also current display method of Tortoise CVS & Tortoise SVN latest development versions. If you need full code to browse you may want look into Tortoise SVN SVN trunk files: srcTortoiseShellContextMenu.cpp, srcTortoiseShellShellExt.cpp and srcTortoiseShellShellExt.h.
All those hacks and recipes would be worthless if only there was simple consistent API for making menu item icons. Unfortunately menu icons, something that was always present in Windows and Microsoft applications, never got any decent API, moreover the methods to get those icons working change for every major Windows release, making us developers wasting our time “porting” our applications to new “shinny” Windows rather than doing something productive.
One thing that is simply unacceptable for me (even more since I now work regularly on OSX) is that Windows system apps and Microsoft regular applications are using so many UI hacks and mods that are never exposed to the developers trough API. Those are either closed libraries like one for Office’s or Visual Studio GUI, or Vista hacks with PARGB that require tricky in memory conversions rather than just pointing hbmpItem to HICON and making Vista to do the conversion on its own.