This is generally caused by not having the OnInitMenuPopup handler defined and the code added as described in step 8 of the installation instructions. So whatever CFrameWnd object is handling the messages for the menu, make sure you have the override in place.
I've seen this question so many times that I decided to try it myself. I've never written a Dialog based app with a menu so I wanted to see what was involved. It's actually quite easy. You basically do all the same stuff as you do in an MDI app. You define an instance of BCMenu in your CDialog derived class and override the menu in the OnInitDialog using SetMenu. Then handle the windows messages OnMenuChar,OnInitMenuPopup,and OnMeasureItem as you do in an MDI app. Make sure you DestroyMenu the class in an OnClose handler. The only issue I found, that's unrelated to the class, is the behavior of the OnUpdate CCmdUI stuff. It's not done the same way as in an MDI app. The OnUpdates are not called when a OnInitMenuPopup message is handled. So I made it behave the same way by grabbing a chunk from CFrameWnd::OnInitMenuPopup and putting it in my Dialog's OnInitMenuPopup handler. If anyone knows a better way, please let me know.
I've also made the project available for download at:
The project contains a pre-release of the next version of the class.
I noticed this too, but interestingly enough it only affects the XP style - switch it back to the old style ("classic"? ) and default items are shown in bold.
This is (to me at least) pretty puzzling, since I can't find anywhere in the code where the font weight is set - the font for each item appears to come from the OS. That being the case, why does it work for one style and not the other?
it has different action because it used two different DrawItem member function:
DrawItem_Win9xNT2000 and DrawItem_WinXP
according to the setting of the static member:
BCMenu::original_drawmode and BCMenu::xp_drawmode
and the operating system you are using.
now i add some codes to the function DrawItem_WinXP to fix this bug.
find the two appearance of code "dispFont.CreateFontIndirect (&lf);" in the function DrawItem_WinXP and replace it with the following:
if(state&ODS_DEFAULT) lf.lfWeight = FW_BOLD;
What puzzled me was the different behaviour between the two versions - I couldn't see anything in DrawItem_Win9xNT2000() to set the bold font for default items, but it seems to work regardless, while DrawItem_WinXP() didn't. Odd.
Let me clear this up. First, the font for the menu is already selected into the hDC before the DrawItem function is called so creating it and selecting it into the device context is not necessary. This is why you don't find any stuff for setting bold text for default menu items. Now why did I do it. Well, I use a memory DC for disabled menu items that can't be selected in XP mode. This was to get rid of some flashing that would occur when the menu redrew the disabled menu option. For the memory DC I needed to set the font and I set the font for all cases, disabled or not. And thus the introduction of the bug in XP mode. So to get rid of the bug you can use the above fix or get the pre-release 3.01 version in the dialog sample:
Note: This sample is in respons to a previous question on using BCMenu with dialog apps.
I fixed it by simply not setting the font for all but the disabled state and adding the bold setting if it's the default item.
P.S. The original 2.63 DrawItem class and the 3.0 DrawItem_Win9xNT2000 does some font stuff but the font is never selected into the DC before drawing the text. Years ago I must have realized the font was already selected but forgot to remove the font code. This is fixed in 3.01.
(Note that this deals with the system menu of the main frame window only. In an MDI application, similar code would be needed in each child frame window).
Although this seems to be close to the "right" solution (the menu is subclassed correctly), the menu isn't painted correctly as you can see in this screenshot.
This looks to me like the menu is being "measured" (WM_MEASUREITEM) incorrectly, and hence displayed truncated. So far, I haven't cracked this (it's probably simple, but I'm not that familiar with owner draw code), but I'll keep looking at it.
FYI if you set the drawing style to "classic" the same thing happens, so this isn't something specific to the XP-style.
I hope this helps - let us all know if you find another solution!
The only issue I found was a compilation error (C2487) when compiling the source files - this is a known issue caused by declaring two static class members on one line in a class which is exported from a DLL (moving them to separate lines fixes it).
MSDN Knowledge Base article Q127900 ("BUG: C2487 Error Occurs If Multiple Static Vars Use dllexport") describes this problem.
The demo that comes with the source includes an example of using BCMenu with multiple document templates. There's an option at the bottom of the view menu that changes the template and the documents menu.
What I was wondering was if anybody knows if this type of functionality is going to be included in .NET? I'd love to use this enhancement in our application but if it is going to be available in the new MFC with .NET then I will probably just wait until February when it is released. I haven't installed any of the .NET beta's so I haven't had a chance to look into this yet.
DaveBevan wrote: ..if it is going to be available in the new MFC with .NET
Remember, MFC and .NET are two completely different frameworks. Nevertheless, this class should work with MFC7, since MFC7 is simply a minor upgrade over MFC6 (which this class was built with). Also, if you're looking for ownerdrawn menus in .NET, check in the .NET section, I've probably seen something similar there.