Subject |
Author |
Date |
|
Timothy Anderson
|
Dec 2, 2005 - 5:53 PM
|
If I have a floating menu put up by right mousing on (in my case) a node in a tree view. When I cancel the popup by left mousing anywhere I get a magical disabled floating menu with my application name in it at the location of the left mouse up. How can I go about trying to figure out where this popup is coming from? This happens with plain old MFC CMenu’s and also with the newfangled CExtPopupMenuWnd’s I switched to. This ONLY happens after a trackpopupmenu and after the menu has already been cleaned off. It’s pretty weird, I must admit.
|
|
Timothy Anderson
|
Dec 2, 2005 - 6:13 PM
|
Should we be getting wm_contextmenu’s as a result of lmouse clicking to dismiss a popup menu? The wm_contextmenu is plowing into the window message hook and creating this popup menu tracker.
|
|
Timothy Anderson
|
Dec 2, 2005 - 6:23 PM
|
My tree control is indeed drag/drop enabled if this is of any help.
|
|
Technical Support
|
Dec 3, 2005 - 1:17 PM
|
We know that the tree control does not send the WM_CONTEXTMENU standard windows message after the right mouse click. The KB222905 article just proves this issue. We may guess you simply forgot to specify the TPMX_DO_MESSAGE_LOOP flag when invoking the CExtPopupMenuWnd::TrackPopupMenu() method.
|
|
Timothy Anderson
|
Dec 5, 2005 - 11:59 AM
|
No, I’m doing the tpmx_do_message_loop thing. It flat doesn’t work unless you have this flag set.
|
|
Timothy Anderson
|
Dec 5, 2005 - 11:53 AM
|
Someone is sending it. This worked perfectly fine until I switched to using the prof-uis toolkit.
|
|
Technical Support
|
Dec 6, 2005 - 10:09 AM
|
It seems we need to take a look at your project to come to any conclusion. Could you send us a test project that demonstrates the problem?
|
|
Timothy Anderson
|
Dec 6, 2005 - 3:43 PM
|
Here’s a zipped up project for you. VC710, from scratch MDI application with all the defaults. Switched doc’s view to a ctreeview, added in some default items for fun, added in rclick menu to tree view (worked OK), switched to prof-uis menu and status bar in main frame, broke. Just click on the "tree" when it first starts, then right click, then left click anywhere. This actually demonstrates two problems of a similar nature I’m having. The phantom wm_contextmenu popup and some weirdness added to the tree control’s popup menu. ftp://ftp.predator-software.com/support/TreeControlTest.zip Let me know what you find.
|
|
Technical Support
|
Dec 7, 2005 - 6:57 AM
|
The answer is simple. The problem is in the CTreeControlTestView::OnNMRclick() method. You forgot to mark the message as handled and to suppress the default handling. You need to assign 1 to the *pResult parameter if you handled the message successfully or 0 otherwise: *pResult = 1; // handled
*pResult = 0; // not handled With the standard menu, the problem does not occur because Prof-UIS adds its own built-in popup menus if there is no user implementation.
|
|
Timothy Anderson
|
Dec 7, 2005 - 4:52 PM
|
I have administered a dope slap to myself on your behalf!
|
|
Timothy Anderson
|
Dec 6, 2005 - 3:34 PM
|
When I left the original frame menu alone and added just the rclick popup everything worked fine. When I added in the prof-uis status and menu bar to the main frame then I got a weird double-menu in the rclick menu popup and the fantom wm_context came flying around again. Where can I post my sample app?
|
|
Timothy Anderson
|
Dec 6, 2005 - 1:20 PM
|
I’ll see if I can build a small example. I got stuck on something else yesterday, but I was able to verify the wm_context menu isn’t coming into the tree control at least. I’m sure you guys are better at tracking down all these goofball windows messages than I am, however.
|
|
Technical Support
|
Dec 7, 2005 - 1:53 AM
|
|