Will you ever create a CMenu class in future to handle menus? It would be better if the menu class redraw itself rather than the CFrameApp class.
At this stage I doubt that a CMenu class would add much benefit. Perhaps you could provide an example of the code you're struggling with.
Remember that the CMenu (provided by MFC) is just a collection of thin wrappers around the various menu related WinAPI functions. It provides no additional functionality.
First of all, let me say that i am a beginner- in both Win32++ and WINAPI. I just want to ask that is there any way to use menu as an object? for example, say if i create a class CoolMenu that is derived from CMenu, Can CoolMenu draw it's own style and can it be applied to every menu- even system menu. Is there a way to do that? so that i can say
and it automatically changes the menu to another style and draws the menu in its own style.
and i found few bugs in the current Menu bar.
-When using visual C++ 6 with "small code" optimization, the menu bar doesn't work.It hangs the program throwing an exception.
- When there are lot of menu items, like in language menu of notepad++, the menu doesn't work properly. When i try to select one of the submenu, it chooses the main menu behind it instead.
And finally, if i want to create a menu class, which class should i derive from?
sorry for poor English
Its up to you, but the menu object may not be the best place to the drawing. When a menu needs to be "owner-drawn" it sends messages like WM_DRAWITEM and WM_MEASUREITEM to the window which owns the menu. For example, in Win32++ these messages are handled in CFrame::WndProcDefault. As a result any menu owned by the frame (including application popup menues) are rendered by CFrame::OnDrawItem. There would be nothing to stop you overridding OnDrawItem in CMainFrame to alter the drawing of menu items if you like.
By the way, in my experience, attempting to perform owner-drawing on system menues is a bad idea. With effort it can be done, but the techniques I've seen require unsupported hacks that may not be supported on all Windows operating systems.
I was a bit confused by your mention of a bug in the "Menu bar" and "small code" optimization. If you feel this relates to Win32++, let me know. Likewise for the menu issue for "notepad++".
As for your home grown CMenu class, it probably shouldn't inherit from any other class. It would presumably have a private HMENU member which could be assigned in one of its constructors, enabling you to say something like:
You would also presumably use operator overloading to allow your CMenu object to be used anywhere a HMENU could be used. Win32++ uses this trick to allow a CDC object to be used for a HDC. I would expect WTL do have a CMenu class. There is nothing to stop you having a look at its code to see how it might be done.
The alternative (without CMenu) would be to simply say:
HMENU MyMenu = GetSystemMenu();
PS: Your English is fine.
CFrameWindow draws the menu bar.That's fine. But what if i want to use the same cool-looking menus as right context menu in a rich edit control? or for any other controls. rewriting the code many times in not a nice way. I want my menu to r
Regarding the bug, I think the first bug is not of win32++ but of visual c++ 6 because it doesn't appears in other higher versions of visual studio. The second bug is surely of win32++. Take the Notepad sample for example. There are two sub menus in "view". they are "tool bar" and "status bar". Increase the number of sub menus to about 20 or 30 so that you have to scroll the menu to see all items. press the view menu- the sub menu will appear in the right side- part of it covering the help menu header. move the mouse up so that the cursor is placed in the submenu of view which lies above the help header.the submenu of view dismisses and the submenu of help pops out. I think this is an unusual behavior because it is very hard for the user select the submenu that unfortunately falls about the help menu header.
sorry! mistakenly pressed post
the first paragraph is
CFrameWindow draws the menu bar.That's fine. But what if i want to use the same cool-looking menus as right context menu in a rich edit control? or for any other controls. rewriting the code many times is not a nice way. I want my menu to receive it's messages itself just like message reflection for controls.
You can simply use the Frame's HWND as the handle of the owner window for TrackPopupMenu (or TrackPopupMenuEx). The frame will then handle the owner draw for the menu.
Remember, a menu doesn't recieve messages. It sends messages to the window that owns it.
Just a quick note to advise that I fixed the probelm with very large menus you referred to in "notepad++".
If you're able to use SVN you will be able to download the latest copy from SourceForge.