|
I've seen this too. but only in 256 color mode. Higher modes seem OK !
|
|
|
|
|
See below memo -> 'Re: Painting bug with submenus'
This problem has same reason.
|
|
|
|
|
When I use 8 bits (or higher) Color bitmaps in the menu they are not drawn transparent?
I use this code to attach a Imagelist :
m_ImageList.Create(16, 16, ILC_COLOR8, 0, 10);
CBitmap bm;
bm.LoadBitmap(IDB_INFO);
m_ImageList.Add(&bm, RGB(192, 192, 192));
CMenuXP::SetMenuItemImage (ID_OPTIONS_LANGUAGE_YOURLANGUAGEHEREMAILME,
m_ImageList, 0);
Anybody a clue ?
thanks in advance,
Eric
|
|
|
|
|
i had the same problem. the solution is simple:
you need to add the ILC_MASK flag to the nFlags parameter
of CImageList::Create(), so your
m_ImageList.Create(16, 16, ILC_COLOR8, 0, 10);
becomes
m_ImageList.Create(16, 16, ILC_COLOR8 | ILC_MASK, 0, 10);
that's it!
|
|
|
|
|
I know this is an old article, but it doesn't matter if I compile to code myself or run the precompiled exe's, the combo box, and many of the buttons, are disabled.
How do I enable them?
using:
Win 2000 Pro, VS 6.0 SP5
|
|
|
|
|
Did you really try it ?
Type some text in the MLE...
|
|
|
|
|
Type in any text and mark some of the text and the combobox as well as most icons will be enabled.
|
|
|
|
|
I ran into a bug with CMenuXP in my app. In addition to CMenuXP, my app uses an ownerdrawn statusbar. In Debug mode everything worked fine, however, in Release mode my ownerdrawn statusbar panes kept drawing like a menu items.
The bug was that the WM_DRAWITEM message was being sent for the statusbar but the DRAWITEMSTRUCT::CtlType was set to ODT_MENU (or some other random value -- an uninitialized variable maybe??).
Because the CMenuXP code hooks into the message loop and gets first crack at handling WM_DRAWITEM, it was taking over and drawing the statusbar pane as a menu item. This was in Release mode only (which made it all the more difficult to track down).
CMenuXP tries to protect against something like this with the following code:
<br />
bool CMenuXP::OnDrawItem (DRAWITEMSTRUCT* pDrawItemStruct, HWND hWnd)<br />
{<br />
if ( pDrawItemStruct->CtlType != ODT_MENU )<br />
{<br />
return false;<br />
}<br />
ASSERT (pDrawItemStruct->CtlType == ODT_MENU);<br />
But this was not enough because, as I said, in Release mode CtlType was coming thru with a value of ODT_MENU for the statusbar pane.
I fixed this by making the above check a little more stringent:
<br />
bool CMenuXP::OnDrawItem (DRAWITEMSTRUCT* pDrawItemStruct, HWND hWnd)<br />
{<br />
if ( pDrawItemStruct->CtlType != ODT_MENU ||<br />
!::IsMenu((HMENU)pDrawItemStruct->hwndItem) )<br />
{<br />
return false;<br />
}<br />
ASSERT (pDrawItemStruct->CtlType == ODT_MENU);<br />
Just wanted to share in case anyone else runs into this.
-Frank
|
|
|
|
|
RUN IN WINDOWS2000.
when menu is upturned ,the left of the menu is not in correct position.
when i put the form/window at the bottom of the desktop,while i click an item of the menu bar,the menu is upturned,but the left of the menu has an excursion.
__________
|...............|
|.item1's....|
|.submenu..|
|..............|
|..............|
|..............|
|_________|
_____________________________________________________
item1 item2 item3 item4
_______________________________________________________________
how to solve this problem ?
|
|
|
|
|
I was able to plug this into my project with no problems and am extremely satisfied with the quality of the code. Thanks so much for sharing this!
|
|
|
|
|
If I move the mouse over a menu item which has a submenu, the submenu displays, then I move the mouse to some other menu item, the submenu disappears, but the right border of the first menu has parts of the submenu left in it. It seems as if the Non-Client area/border of the menu is not repainting when a submenu goes away. I have tried to find a way to refresh the menu, with no luck. Anyone else seeing this? Any ideas how to fix?
-Frank
|
|
|
|
|
After 'OnNCPaint()' function , call 'UpdateWindow()' API
case WM_NCPAINT:
if ( (pWnd=CWndMenuXP::FromHandle (hWnd)) != NULL )
{
pWnd->OnNcPaint();
UpdateWindow(hWnd);
return 0;
}
break;
|
|
|
|
|
If only it were that simple. I tried that before (and I just retried it now) and the same problem still appears. Thanks for the suggestion.
-Frank
|
|
|
|
|
case WM_NCPAINT:
if ( (pWnd=CWndMenuXP::FromHandle (hWnd)) != NULL )
{
LRESULT lResult = CallWindowProc(oldWndProc, hWnd, uMsg, wParam, lParam);
pWnd->OnNcPaint();
UpdateWindow(hWnd);
return lResult;
}
break;
|
|
|
|
|
Sorry for not being clear...that is what I am doing (see below). The addition of the UpdateWindow() call does not seem to help.
<br />
case WM_NCPAINT:<br />
{<br />
LRESULT lResult = CallWindowProc(oldWndProc, hWnd, uMsg,<br />
wParam, lParam);<br />
<br />
if ((pWnd=CWndMenuXP::FromHandle (hWnd)) != NULL)<br />
{<br />
pWnd->OnNcPaint();<br />
}<br />
return lResult;<br />
}<br />
break;<br />
-Frank
|
|
|
|
|
it works! can you tell me the reason?
|
|
|
|
|
I am using VC 6.0... when i use CButtonXP for more then one Buttons on the same Dialog it works fine but.. if i use CComboBoxXP for more than one Combo on the same Dialog it throws an Exception n crashes... It works fine with One ComboBox... ... cant understand the problem... i am not using any Menu on the Dialog... I tried putting Two ComboBoxes on the .NET Sample code which i downloaded along the classes.. it works fine there but not in my application...
|
|
|
|
|
The system menu (right-click the main window's caption) of MDI.exe is incorrectly painted.
Chen Hao
ch@sothink.com
|
|
|
|
|
I've been using CMenuXP for some time now in my app and it has been great! However, I have noticed a bug. In some cases in my app a very long popup menu is opened with TrackPopupMenu. This popup menu contains so many items that all of them cannot be displayed on screen. To accomodate, the menu puts an up arrow at the top of the menu and a down arrow at the bottom. These arrows allow the user to scroll up/down thru the menu items. Something like this:
+-----------------+
| /\ |
| Menu Item 1 |
| Menu Item 2 |
| Menu Item 3 |
| . |
| . |
| . |
| Menu Item N |
| \/ |
+-----------------+
The bug is that the entire rect containing the up/down arrow does not paint -- you can see the app/desktop behind showing thru. When you move the mouse over the location where the up/down arrow is supposed to be, the arrow shows up. The rest of the rect never paints.
The area for the up/down area does not come thru as a menu item. How do you draw this part of the menu? I've tried some things in OnNcPaint, but it doesn't seem like the right place to do it. Any ideas?
-Frank
|
|
|
|
|
Well, I figured it out...sort of. To fix this I updated the OnNCPaint function to fill the background just like a menu item. In most cases this gets painted over by the item drawing. However, when the menu is so long that it displays scroll arrows as the first and last items, this background shows thru and now just looks like all the other menu items.
I also added code to OnNCPaint to draw the up/down scroll arrows. Again, in most cases this gets drawn over by the items, but when the scroll arrows are shown, the OnNCPaint drawing shows up. I even did it so that it uses XP Visual Style scroll arrows if running on XP with Visual Styles enabled. The only problem is, when the mouse cursor is moved over the scroll items, the system redraws the scroll arrows and my nice ones get painted over by the system. I can't figure out which message is being sent that is causing this or how the menu is drawing the item. All my attempts to work around this have failed. Things are much better now than before so things aren't so bad.
I also fixed the code to not highlight disabled items and I fixed the drawing of the > arrow for submenus (I added code to do it and stop the system from drawing it also).
If anyone has any ideas on how to handle the scroll arrow drawing described above, please let me know.
If anyone is interested in the changes I have made, let me know.
-Frank
|
|
|
|
|
I work on an SDI application project. The XP-style menu works fine in main menu. Popups in the main view look perfect too. However, I haven't managed to get it working in dialogs. In this case, context menus are created and maintained by dialog controls in our project. I inserted the CMenuXP macros to such a control and added the SetXPLookNFeel call. The result was quite poor. The menu didn't have any shading (it had the old-style frame instead) and submenus couldn't be opened. Only menu items were displayed correctly and highlighting worked. I would be grateful if anyone can help me to solve this issue.
|
|
|
|
|
I solved the problem with shading. The solution is quite simple. The procedure hooking loaded windows (CWndMenuXP::WindowsHook) automatically returns if the window is not a foreground window (frame or dialog window) and no hook is registered. It causes the messages for controls are not processed by CWndMenuXP::SubClassMenuProc and the menu border is therefore painted in the old style. To overcome it, just register the foreground window to have XP style enabled, most likely in the PreSubclassWindow handler:
CMenuXP::SetXPLookNFeel(GetForegroundWindow(),true);
This solution can however cause problems if you mix original and XP style menus on the same dialog. To avoid that, you can activate the XP-style just when the context menu is displayed and deactivate the style after it:
CMenuXP::SetXPLookNFeel(GetForegroundWindow(),true);
pPopup->TrackPopupMenu(TPM_LEFTALIGN,point.x,point.y,this);
CMenuXP::SetXPLookNFeel(GetForegroundWindow(),false);
|
|
|
|
|
Does this all work OK on win NT and 98? Are there any problems on these systems.
|
|
|
|
|
I tested the code under XP and it looks like for the toolbar, there is an rectangular contour about the toolbar that is not rendered.
This seems to occur on starting up the dialog, MDI or SDI app.
A very minor issue, but I wanted to mention it.
It works fine in Win2000.
I'm wondering if people have tested on Win98, Me?
Very fine work.
|
|
|
|
|
Hi, i'm using CMenuXP in all of my applications.
It is one of the best classes i ever found in CodeProject.
No other tool is as easy to integrate.
Now the question:
Do you plan to add support for the new Office XP 2003 style?
If you do, what is the time line?
thanks in advance!
...and it works!
FPF
|
|
|
|