Context Menu and Command Routing Mechanism

I am using  VC 5.0.
In my MDI application  I added a context menu (TrackPopupMenu) to  the CTreeCtrl class inserted into CControlBar. The handlers of the menu commands are implemented in the CMainFrame class. When the bar is docked everything is OK: commands are
handled successfully. BUT when I undock the bar all items in the context  menu become gray. As I understand MFC stop "seeing" the handlers in  CMainFrame.
I guess that something is wrong with the command routing mechanism, but I can't catch what exactly fails.
DimachAsked:
Who is Participating?
 
mrosenConnect With a Mentor Commented:
Ok. I just found out my app has this bug. I haven't tried it out yet, but I'm going to derive my own CToolbar and implement the menu command IDs there.
0
 
mrosenCommented:
Try adding UPDATE_COMMAND_UI messages for each of the menu items in classwizard. This gives you code like this:

In the message map:
ON_UPDATE_COMMAND_UI(ID_REFRESH, OnUpdateRefresh)

void CMainFrame::OnUpdateRefresh(CCmdUI* pCmdUI)
{
     //Just call Enable unless there is some reason not to (from your app)
     pCmdUI->Enable(TRUE);
}
0
 
DimachAuthor Commented:
Even if I artificially enable items, handlers won't be executed when the bar is undocked!

0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

 
DimachAuthor Commented:
Thank you for reply.
Take into account that I have a few tree controls in the bar and I wish each tree has a separate context menu. That is quite similar to the Project workspace window in VC (MFC newsgroups full of questions how to implement features similar to ones Developer Studio has, but I didn’t see anything looking like this). Are you sure that implementation of the menu command IDs in the bar is a good idea?

0
 
mrosenCommented:
To be honest, I'm not sure there. One very unelegant aspect of MFC is the fact that controls in toolbars or dialog bars are processed through the CMainFrame class, not the view class. You should derive each of the tree controls and handle the OnLButtonDown message, calling a TrackPopupMenu at the point given by OnLButtonDown.
0
 
DimachAuthor Commented:
I've solved  the problem.
To call the context menu I used the following code (used in MFC examples attached to VC):

CWnd* pWndPopupOwner = this;
// The following cycle returns different  CWnd for docked/undocked
// control bar:
//    CMainFrame         - for the docked bar
//    CMiniFrameWnd - for the undocked bar
while( pWndPopupOwner->GetStyle() & WS_CHILD )
       pWndPopupOwner = pWndPopupOwner->GetParent();
pPopup->TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON,
                     point.x, point.y, pWndPopupOwner);

As a result CMaintFrame handlers are not called for the undocked control bar. To fix  the bug it's necessary to write:
pWndPopupOwner = AfxGetMainWnd();

0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.