|
Hi Ken,
The problem is,I can download the sample project,build and run it successfully.But when I add the MenuXP to my project it doesnt work.I have followed all the steps as mentioned on the web page.
Thanks a lot.
|
|
|
|
|
I have found 2 problems.
The first problem is when you use MenuXP with an Windows Skin (like WindowBlinds), then the menu looks sometimes (depending on the theme) a little bit ugly.
But a real problem is when you open the context menu on the taskbar of the menu xp app. Then some other application (like Windows Explorer) doesn't show the context menu in the taskbar anymore. The opera browser chrashes after that with an fatal error. There seems to be a real problem!
I have WinNT 4.0 installed, I've tested it with XP and there's no problem.
If you have an proposal for solving this error, please tell me.
thx & cu
Eric
|
|
|
|
|
I've discovered a problem with MenuXP that seems to be an incompatibility with the CComboBox::GetLBText function. If the CComboBox that GetLBText is used on has items that are very long (>1024 characters), an application that uses MenuXP will crash when GetLBText is called.
The last application function that is on the stack is CWndMenuXP::WindowsHook and indeed by removing the call to CMenuXP::InitializeHook the crash is resolved.
I realize this is a very strange report, but I would appreciate any suggestions.
|
|
|
|
|
Just an update, the only resolution I still have is removing the call to InitializeHook().
|
|
|
|
|
There are a couple of improvements that I think need to be made to this code:
1 - The system menu does not appear like the normal system menu, that is the restore, minimize, maximize items have icons instead of icons and captions.
2 - When the toolbar is floating it has the mini-frame window appearence instead of the flat frame appearence like the other XP sytle controls.
Other than this I like this code and simplicity to change the drawing...making it easy to change the appearence to the new Office 03 style (hint hint)
|
|
|
|
|
Good idea...ähemm I would like to get point 2, too...
|
|
|
|
|
As far as requested improvement 1, I had pretty good sucess with adding:
CMenu* pmSystem = GetSystemMenu(FALSE); CMenuXP::SetXPLookNFeel(this,pmSystem->GetSafeHmenu());
To CMainFrame::LoadFrame of my SDI App.
Thanks for a great job,
Larry
|
|
|
|
|
I've inserted your code into my app. Perfect! But if I hover the mouse over a toolbar button, the button is not highlighted. I've found out (up to now), that there is no WM_PAINT generated at mouse hit. Your MDI-sample does (on my XP system, on a w2k system it does not,too). Any ideas?
|
|
|
|
|
Did you add the tbs_flat style ?
|
|
|
|
|
Thanks for answering so fast.
I've tried several modifications. All of them are working ok using your MDI sample on XP, including this one:
if (!m_wndToolBar.Create(this, WS_CHILD | WS_VISIBLE | CBRS_TOP)
{
TRACE0("Failed to create toolbar\n");
return -1; // fail to create
}
Isn't it curious?
But my app does not work and on W2k even your MDI sample does not work.
This is the call stack, setting a breakpoint for bover inside ToolbarXP:
CToolBarXP::OnPaint() line 251
CWnd::OnWndMsg(unsigned int 15, unsigned int 0, long 0, long * 0x0012fc14) line 1825
CWnd::WindowProc(unsigned int 15, unsigned int 0, long 0) line 1585 + 30 bytes
CControlBar::WindowProc(unsigned int 15, unsigned int 0, long 0) line 480 + 20 bytes
AfxCallWndProc(CWnd * 0x003353dc {CToolBarXP hWnd=0x0002020a}, HWND__ * 0x0002020a, unsigned int 15, unsigned int 0, long 0) line 215 + 26 bytes
AfxWndProc(HWND__ * 0x0002020a, unsigned int 15, unsigned int 0, long 0) line 368
AfxWndProcBase(HWND__ * 0x0002020a, unsigned int 15, unsigned int 0, long 0) line 220 + 21 bytes
USER32! 77d13a68()
USER32! 77d13b37()
USER32! 77d1450d()
USER32! 77d1453d()
NTDLL! 77fa4da6()
USER32! 77d1438c()
CWinThread::Run() line 487 + 11 bytes
CWinApp::Run() line 400
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00151f07, int 1) line 49 + 11 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00151f07, int 1) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e614c7()
I think it is a matter of USER32.dll, but what?
|
|
|
|
|
|
I do know. Mr. Stupid had been there and placed code to catch the message inside the inherited toolbar. Grrr !
|
|
|
|
|
Hello,
I have a menu with a submenu. On Highlighting main menu......when sub menu is appearing little triangle on right side of main menu is disappearing. Please tell how to solve this.
Thanks,
Rahul.
|
|
|
|
|
See 'Blue box highlight' thread. I believe this will fix your issue as well.
|
|
|
|
|
Everything worked perfect.... until I tried to set up menus to behave when the user clicked. I mean, the presentation and so on works perfect, but the trouble that I have is that I can't or I don't know where I may introduce the ON_COMMAND(...........), it doesn't work, it seems like nothing is returned, it works the same as if I wouldn't change anything.
I need help, please.
Thank you, Rafael from spain.
MaestroProgramador.Com
Where every source code is loved like a girl.
|
|
|
|
|
Hi,
I have the following strange effect, which is that my main menu captions are overwritten by the captions of submenu. The situation is that I have the same command in both the main menu and some popup-menu's, but that their caption is different.
To illustrate this, in the main menu I have a "Setup" main-item with in this "Setup" menu the items "Setup Size...", "Setup Color..." and "Setup Font...". But the user can also rightclick on an object in my document, and then a submenu appears with Item "Size >" and subitems "10 mm", "20 mm", "30 mm" and "Dialog...".
Now, the mainmenu item "Setup Color..." and the submenu item "Dialog..." both have the same command ID. After retrieving the pop-up menu, the main menu item "Setup Color..." becomes "Dialog..."
A work-around would be to assign a different command ID to the item in the main menu and the submenu and map both command to the same function, but this behaviour is different from the MFC standard menus, so then it would at least be something to mentions in the description of CMenuXP.
|
|
|
|
|
I agree
This is a major limitation of my class.
And the article should be more explicit about that.
|
|
|
|
|
Okay, would this mean I'd try the workaround by specifying different command ID's then trying to/waiting for the CMenuXP to be fixed/enhanced for this?
|
|
|
|
|
I converted my application to this menu style and now my application is not Windows 95 compatible.
These errors are displayed:
"... exe file is linked to missing export USER32.DLL: Track Mouse event" and "Unable to execute file ... .exe. Create process failed: Code 31."
If I exclude calls to CMenuXP functions in the code using GetVersionEx for Windows 95 users, can this problem be overcome or am I stuck with a Windows 95 incompability if I use this menu style which I very much like?
|
|
|
|
|
I remembered that I used TrackMouseEvent is some button code which did not cause problems so I adopted these changes:
commented out this line in tools.cpp
//extern "C" WINUSERAPI BOOL WINAPI TrackMouseEvent (LPTRACKMOUSEEVENT lpEventTrack);
and changed all occurrences of ::TrackMouseEvent (&tme);
to ::_TrackMouseEvent (&tme);
I don't know whether the last change is significant but the result of these changes is no more runtime errors and the menu system seems to work OK for Windows 95.
|
|
|
|
|
Hi,
I'm trying to use the CMenuXP Style, but i have troubles with the toolbars. The area outside the clipbox (e.g. the area set bij SetBorders(), where the gripper is drawn) is not erased. Thus the border for the CToolBarXP's looks weird!
I've tried to make a clean project with the CMenuXP style, and for that clean project, the toolbars are ok. Now it looks to me that I am missing something? The OnNcPaint() function is never overriden. I carefully checked every declaration and macro, but everything looks fine in the original project, still the Toolbars those weird borders.
I uploaded a picture to www.vdkolk.nl/~marco/ncerr.png so that you can see what I mean. I could also give some code snippets if you like.
Regards,
Marco.
|
|
|
|
|
I have not enough element to solve your problem.
Some directions:
In my project, I completly remove 3d borders (see the afxData2 object in CToolBarXP.cpp). In your screenshot borders seem to be present)
Are you sure the not painted area is from toolbar ? (perhaps it's the parent toolbar area)
Try to handle WM_NCPAINT to paint yourself this area. You also must paint the gripper.
Remove each method of my class to understand where the problem come from.
If you can send me a compilable project that have the problem, I can debug it and try to find a solution.
Regards
Jean-Michel
|
|
|
|
|
After one full day of disabling pieces of code, I found the problem. The origin of this problem was a special resource I added in order to have Windows XP styles (resource type 24, id 1, with some special XML code containing a manifest), actually also some article here on CodeProject. This resource was already added for quite a long time to my project, but I used some other flat toolbar control, that drew it own grippers.
Actually when I complete removed the CMenuXP code and the other flat toolbar control, the grippers where still transparent, but here I was using the standard MFC CToolBars! So nothing wrong with CMenuXP. Cool code, and now just re-enabled it my project, after removing the resource! Also thanks for your quick answer. Your remark "Remove each method of my class to understand where the problem come from", actually was the clue to finding it!
Thanks!
|
|
|
|
|
To continue with this, I added the resource type 24 XML code again, but removed the style TBSTYLE_FLAT when creating the toolbars. Now the toolbars look fine, and still the dialogs have the WindowsXP style!
|
|
|
|
|
Hmmm, sorry to fill up this thread here, but removing TBSTYLE_FLAT doesn't work with the Windows classic style. A solution can be found in the threads in JM LE FOL's article on CToolbarXP.
|
|
|
|
|