I'm having a problem with the RMB Context menus, In my main frame I have a grid control with the RMB context menu event. The shortcut keys appear correctly. See Copy for Ctrl + C,Paste for Ctrl + V, etc...
Then I have a dialog with already a bunch of codes from other dev's. And this dialog somehow makes the RMB Context menu funky. The shortcut keys no longer appear. It may be caused by altering the PreTransalateMessage and some messages are not going through right or maybe some shell functions that may had a conflict. Because when you notice the window it's still using the windows aero basic theme while I'm using Windows 10 because of the pin icon beside the minimize.
This is the code used in the mainframe as well as in the dialog.
void MyDialog::OnContextMenu(CWnd* pWnd, CPoint ptMousePos)
{
CMenu *menuRightClick;
menuRightClick->LoadMenu(IDR_RIGHTCLICK);
CMenu *pPopupVitmMenu;
pPopupVitmMenu = menuRightClick->GetSubMenu(9);
ASSERT(pPopupVitmMenu);
if (pPopupVitmMenu)
{
CPoint point;
::GetCursorPos(&point);
CMFCPopupMenu* pPopupMenu = new CMFCPopupMenu;
CMFCPopupMenu* pPopup = CMFCPopupMenu::GetActiveMenu();
//close already poped up menus, if any.
if (pPopup != NULL)
pPopup->CloseMenu();
pPopupMenu->Create(this, point.x, point.y, pPopupVitmMenu->Detach(), FALSE, TRUE);
pPopupMenu->ShowWindow(SW_SHOW);
}
}
This maybe related or unrelated but the old context menu doesn't get dimissed when you RMB on another area. It only disappears when you click outside the application(Desktop,Taskbar).
I know the information is vague, but that's all I can provide.
Thanks in advance!
Use theApp.GetContextMenuManager() to get access to CContextMenuManager. Where theApp is the main CWinApp class. It should be calling InitContextMenuManager() during initialization.
CMenu menu;
menu.LoadMenu(IDR_MAINFRAME);
CMenu *popup = menu.GetSubMenu(0);
if(popup)
{
CContextMenuManager *manager = theApp.GetContextMenuManager();
if(manager)
//for CDialogEx:
manager->ShowPopupMenu(popup->Detach(), p.x, p.y, this, TRUE, TRUE, FALSE);
//for CDialog:
//manager->ShowPopupMenu(popup->Detach(), p.x, p.y, this, FALSE, TRUE, FALSE);
}
Note that the 5th parameter should be TRUE for CDialogEx, and FALSE for CDialog
Related
(Update, see original question below)
After doing a bit of digging, I'm basically trying to understand the following; In the context of an MDI application, if a menu (which is associated with a specific CChildWnd) has an MF_OWNERDRAW, why are the ON_WM_MEASUREITEM and ON_WM_DRAWITEM events send to the CMainWnd instead of the CChildWnd?
In my InitInstance, the document template is registered and the associated menu is modified to add the MF_OWNERDRAW:
BOOL CMyApp::InitInstance()
{
// ...
CMultiDocTemplate* pDocTemplate;
pDocTemplate = new CMultiDocTemplate(
IDR_CHILDFRAME,
RUNTIME_CLASS(CFooDoc),
RUNTIME_CLASS(CFooWnd),
RUNTIME_CLASS(CFooView)
);
if (pDocTemplate->m_hMenuShared != NULL) {
CMenu* pMenu = CMenu::FromHandle(pDocTemplate->m_hMenuShared);
// Add MF_ONWERDRAW to the items that need it.
pMenu->ModifyMenu([item_id], MF_BYCOMMAND | MF_OWNERDRAW, [item_id]);
}
AddDocTemplate(pDocTemplate);
// ...
}
So, once the document template is registered, the menu associated with the document/frame is modified to add the MF_ONWERDRAW flag to each of the required items (the color selection items in my case).
However, why are the OnMeasureItem and OnDrawItem events send to the CMainWnd and not the CFooWnd? And how can I direct the events to the CFooWnd instead?
The reason I'am asking, if I have 5 different types of documents in my MDI application, each needing custom menus, then the CMainWnd basically becomes a mess of message handling. The logical place for the custom menu logic is in the CChildWnd, not the CMainWnd.
Original question:
I'm doing some work on a very old application (MFC 4.2) and I'm running into a problem with drawing in a menu item.
The original application has a menu to select a color and it actually draws the colors in the menu when opened so it easier for the user to select the color.
The behavior for this implemented in CMainWnd using the OnMeasureItem and the OnDrawItem.
class CMainWnd : public CMDIFrameWnd
{
DECLARE_DYNCREATE(CMainWnd)
protected:
afx_msg void OnMeasureItem(int, LPMEASUREITEMSTRUCT);
afx_msg void OnDrawItem(int, LPDRAWITEMSTRUCT);
DECLARE_MESSAGE_MAP()
};
Then, in the implementation (omitted bits and pieces for brevity):
BEGIN_MESSAGE_MAP(CMainWnd, CMDIFrameWnd)
ON_WM_MEASUREITEM()
ON_WM_DRAWITEM()
END_MESSAGE_MAP()
void CMainWnd::OnMeasureItem(int nIDCtl, LPMEASUREITEMSTRUCT lpmis)
{
lpmis->itemWidth = ::GetSystemMetrics(SM_CYMENU) * 4;
lpmis->itemHeight = ::GetSystemMetrics(SM_CYMENU) * 1;
}
void CMainWnd::OnDrawItem(int nIDCtl, LPDRAWITEMSTRUCT lpdis)
{
CDC dc;
dc.Attach(lpdis->hDC);
CBrush* pBrush;
// draw the hover/selection rectangle
pBrush = new CBrush(::GetSysColor((lpdis->itemState & ODS_SELECTED) ? COLOR_HIGHLIGHT :
COLOR_MENU));
dc.FrameRect(&(lpdis->rcItem), pBrush);
delete pBrush;
// load a checkbox icon into a bitmap
BITMAP bm;
CBitmap bitmap;
bitmap.LoadOEMBitmap(OBM_CHECK);
bitmap.GetObject(sizeof(bm), &bm);
// if color/item selected then draw the checkbox
if (lpdis->itemState & ODS_CHECKED) {
CDC dcMem;
dcMem.CreateCompatibleDC(&dc);
CBitmap* pOldBitmap = dcMem.SelectObject(&bitmap);
dc.BitBlt(
lpdis->rcItem.left + 4,
lpdis->rcItem.top + (((lpdis->rcItem.bottom - lpdis->rcItem.top) - bm.bmHeight) / bm.bmWidth,
bm.bmHeight,
&dcMem,
0,
0,
SRCCOPY
);
dcMem.SelectObject(pOldBitmap);
}
// draw the actual color bar
pBrush = new CBrush(CPaintDoc::m_crColors[lpdis->itemID - ID_COLOR_BLACK]);
CRect rect = lpdis->rcItem;
rect.DeflateRect(6, 4);
rect.left += bm.bmWidth;
dc.FillRect(rect, pBrush);
delete pBrush;
dc.Detach();
}
What the OnDrawItem does is; it draws a horizontal color bar with a color, prefixed by a check icon if that color is selected and the menu item being hovered over is highlighted by a box being drawn around it.
However, since I'm turning this application into a Multidoc application and I don't really feel that this logic should be in the CMainWnd (since none of the other documents will have this type of menu), but that it should be part of the CChildWnd (which inherits from CMDIChildWnd).
But when I move this logic to that class, when I run the application, I get following message in the console logger:
Warning: unknown WM_MEASUREITEM for menu item 0x0082.
And none of the custom menu behavior seems to work.
so, the question is; How can move the custom behavior of a menu into the frame class of an MDI document rather than having it located in the application main frame?
I figured out a work around. Not ideal but I can understand that this is a quirk in the framework, i.e. the menu seems to be part of the MainWnd so from a technical point of view, that is where the ON_WM_MEASUREITEM and ON_WM_DRAWITEM would be handled.
Anyhow, my work around. Basically capture the events in the MainWnd and then delegate the behaviour to the ChildWnd. The trick here (I guess) is to figure out what ChildWnd to delegate to since in an MDI application there can be any number of different ChildWnd's (each with their own Document and View types).
The work around:
void CMainWnd::OnMeasureItem(int nIDCtl, LPMEASUREITEMSTRUCT lpmis)
{
CMDIChildWnd* pActiveWnd = MDIGetActive();
if(pActiveWnd && pActiveWnd->IsWindowVisible())
{
if(pActiveWnd->IsKindOf(RUNTIME_CLASS(CMyChildWnd))) {
CMyChildWnd* pMyChildWnd = (CMyChildWnd*)pActiveWnd;
CMyChildWnd->DoMeasureItem(nIDCtl, lpmis);
}
}
}
void CMainWnd::OnDrawItem(int nIDCtl, LPDRAWITEMSTRUCT lpdis)
{
CMDIChildWnd* pActiveWnd = MDIGetActive();
if(pActiveWnd && pActiveWnd->IsWindowVisible())
{
if(pActiveWnd->IsKindOf(RUNTIME_CLASS(CMyChildWnd))) {
CMyChildWnd* pMyChildWnd = (CMyChildWnd*)pActiveWnd;
CMyChildWnd->DoDrawItem(nIDCtl, lpdis);
}
}
}
Pretty straight forward, in the context of the MainWnd, get a pointer to the active MDI ChildWnd, check if it is active, then check the type by using IsKindOf and RUNTIME_CLASS and if so, voila, delegate the behavior to the ChildWnd. To DoMeasureItem and the DoDrawItem are just public methods implemented on the ChildWnd (see question for details).
I have this code :
m_pBtnCom = new CButton();
m_pBtnCom->Create(_T("Push"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON|BS_TEXT|BS_VCENTER|BS_CENTER, rc, this, BTN_CMT);
Where:
this = my derived CWnd class
rc = CRect button position
BTN_CMT = button id
Current context:
If I disable the parent CWnd by calling EnableWindow(FALSE), even if I call the function EnableWindow(TRUE) on the button (m_pBtnCom->EnableWindow(TRUE)), the latter remains disabled; Therefore, nothing works on it: click, tooltip, ...
I tried to remove WS_CHILD, without success
Question:
Is it possible to activate the button when the window (argument this in my code) is disabled?
Child window can't be independently enabled when parent window is disabled. You can instead enable all children, then go back and enable the particular button.
Note, if you have IDCANCEL button, and you disable it, then the dialog's close button is not functioning either and it gets confusing. You may want to avoid disabling the cancel button and override OnCancel
void CMyDialog::enable_children(bool enable)
{
auto wnd = GetWindow(GW_CHILD);
while (wnd)
{
wnd->EnableWindow(enable);
wnd = wnd->GetWindow(GW_HWNDNEXT);
}
}
BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
enable_children(FALSE);
//re-enable one button
if(GetDlgItem(IDCANCEL)) GetDlgItem(IDCANCEL)->EnableWindow(TRUE);
return TRUE;
}
void OnCancel()
{
MessageBox(L"cancel...");
CDialog::OnCancel();
}
Added Update 2 on 3/29/2022
My MFC app has the menubar, toolbar, and status bar all working correctly. I am at the point I'm adding creature features...one that really annoys me is the choice of permanently locking them or allow them to float at runtime...I've looked high and low and I've yet to see an example where a user can allow this feature to be dynamically changed once the app is up and running. The first function is from the app which works correctly. NOTE: I have the items allowing docking commented out as this was my test code..I know that those are the lines that enable or disable docking at run time....-> // enable docking
int CMainFrame::OnCreate(LPCREATESTRUCT pptCreate)
{
CMFCVisualManager::SetDefaultManager(RUNTIME_CLASS(CMFCVisualManagerVS2005));
if ( -1 == CMDIFrameWndEx::OnCreate(pptCreate) )
return -1;
// create menu bar
if ( !m_wndMenuBar.Create(this) )
return -1;
m_wndMenuBar.SetPaneStyle(m_wndMenuBar.GetPaneStyle() | CBRS_SIZE_DYNAMIC | CBRS_TOOLTIPS | CBRS_FLYBY);
// prevent the menu bar from taking the focus on activation
CMFCPopupMenu::SetForceMenuFocus(FALSE);
// set the visual manager and style based on persisted value
theApp.m_nAppLook = theApp.GetInt(_T("ApplicationLook"), ID_VIEW_APPLOOK_VS_2008);
OnApplicationLook(theApp.m_nAppLook);
// create tool bar
if ( !m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD|WS_VISIBLE|CBRS_TOP|CBRS_GRIPPER|CBRS_TOOLTIPS|CBRS_FLYBY|CBRS_SIZE_DYNAMIC) || !m_wndToolBar.LoadToolBar(IDR_MAINFRAME) )
return -1;
// create status bar
if ( !m_wndStatusBar.Create(this) || !m_wndStatusBar.SetIndicators(miIndicators, sizeof(miIndicators)/sizeof(UINT)) )
return -1;
// enable docking
//m_wndMenuBar.EnableDocking(CBRS_ALIGN_ANY);
//m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
m_wndToolBar.EnableToolTips(TRUE);
EnableDocking(CBRS_ALIGN_ANY);
DockPane(&m_wndMenuBar);
DockPane(&m_wndToolBar);
// enable Visual Studio 2005 style docking window behavior
CDockingManager::SetDockingMode(DT_SMART);
// enable Visual Studio 2005 style docking window auto-hide behavior
EnableAutoHidePanes(CBRS_ALIGN_ANY);
// create docking windows
if (!CreateDockingWindows())
{
TRACE0("Failed to create docking windows\n");
return -1;
}
m_wndOutput.EnableDocking(CBRS_ALIGN_ANY);
DockPane(&m_wndOutput);
return 0;
}
So I've created a menu item that toggles a flag to turn "docking" on and off. The variable switches correctly.. but the command execution of turning the dock "3 dots" on the left side of the menubar and toolbar always remain...i.e. never goes from Float to Dock mode and vice versa. The logic of the toggle works as I can see in my debugging status window the entry points of TRUE and FALSE are seen each time I click the menu. So I guess the question is, can these items be dynamically turned from FLOAT to DOCK without destroying the window and trying to reinit it which would be a visual disaster?
void CMainFrame::UserDockingBarsOption()
{
CMainFrame* pMainFrame = (CMainFrame*)AfxGetMainWnd();
pMainFrame->m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--CMainFrame::UserDockingBarsOption()"));
if (UserDockingFlag == TRUE)
{
m_wndMenuBar.EnableDocking(CBRS_ALIGN_ANY);
m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
EnableDocking(CBRS_ALIGN_ANY);
UserDockingFlag = FALSE;
pMainFrame->m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--Inside True"));
}
else
{
m_wndMenuBar.EnableDocking(FALSE);
m_wndToolBar.EnableDocking(FALSE);
EnableDocking(FALSE);
UserDockingFlag = TRUE;
pMainFrame->m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--Inside False"));
}
}
Update 1:
So like my other posts, I'm back after a family matter. I revisited this and because I'm using:
CMFCMenuBar m_wndMenuBar;
CMFCToolBar m_wndToolBar;
and the only member I can find is IsFloat as a question, not an execute. So it was mentioned I can float or dock it via:
https://learn.microsoft.com/en-us/cpp/mfc/docking-and-floating-toolbars?view=msvc-160
Every example that I see is done within the OnCreate which does not help me as I can't recall it after it's already the child is already constructed. So my thought was to invalidate the toolbar, destroy the toolbar, recreate the tool bar with the user switch of dock or float, and then reorganize the toolbars. I have "most" of this working except for the actual switch control aspect to rebuild the menu with the user option of floating the toolbar or docking it.
What I did in my property sheet is created two buttons for two seperate functions to see if I can get each piece of this to work. One button is destroy the toolbar, the other button is create i.e. recreate the toobar....and both of those "work".
This is all being done in the MainFrame.cpp for simplicity of the member variables, I may move it later if I can get it working.
There are the two functions:
Destroy Function:
void CMainFrame::OnToolBarDestroy()
{
m_wndToolBar.Invalidate();
m_wndToolBar.DestroyWindow();
RecalcLayout();
//OnToolBarCreate();
//m_wndToolBar.ShowPane(FALSE, FALSE, FALSE); // Hide toolbar
}
Recreate Toolbar outside of OnCreate
int CMainFrame::OnToolBarCreate()
{
// TODO: Add your implementation code here.
if (m_wndToolBar)
{
m_wndOutput.AddStringStatusTab(_T("Error: Icon toolbar is already active, action cancelled"));
m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--Error: Icon toolbar is already active, action cancelled"));
return -1;
}
// Create ToolBar toolbar
if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP
| CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
{
TRACE0("Failed to Create Dialog ToolBar\n");
return -1;
}
CRect rcClientOld;
CRect rcClientNew;
GetClientRect(rcClientOld);
RepositionBars(AFX_IDW_CONTROLBAR_FIRST, AFX_IDW_CONTROLBAR_LAST, 0, reposQuery, rcClientNew);
//m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
//DockPane(&m_wndToolBar);
RecalcLayout();
//m_wndToolBar.ShowPane(TRUE, FALSE, FALSE); // Show toolbar
return -1;
}
So what is commented out that would make it "work" assuming following the OnCreate code order up to this point:
//m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
//DockPane(&m_wndToolBar);
What happening is the successful destroy, and successful rebuild of the menu.
What I need for switch control is to either have the line active for floating or commented out for docked which I have also done in OnCreate but since this is for the rebuilt menu, I need this to follow that method switching in or out this line: //m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY); ...but when I do....the toolbar gets all garbled up / missing all icons and I have to nuke the registry keys for the workspace to "try again"...
Any ideas on how I can make this work? I feel like I'm This close to getting it...I'm just unsure what I may be missing here to get across he goal line.
Update 2
So I got the toolbar to come out of docked to float with modified code below without restarting the app. But there are issues, it seems to be drawing "ghost" bars underneath. If I double click the 3 dots, it will detach and the bar will float....GREAT! But, it leave a "mirror" behind....if I double click the floating menu, it redocks to the frame.
I know I'm close, I'm just missing a piece to finish this off. I've added the code below and a few screenshots of wha I'm seeing.....the point is I is "working", but I'm missing something...can anyone help?
OnDestroy method updated:
int CMainFrame::OnToolBarDestroy()
{
//if (!m_wndToolBar)
//{
// m_wndOutput.AddStringStatusTab(_T("Error: Icon toolbar is already removed, action cancelled"));
// m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--Error: Icon toolbar is already removed, action cancelled"));
// return -1;
//}
//m_wndToolBar.Invalidate();
//m_wndMenuBar.DestroyWindow();
m_wndToolBar.DestroyWindow();
//m_wndToolBar.AdjustDockingLayout();
//RecalcLayout();
//OnToolBarCreate();
//return 0;
CRect rcClientOld;
CRect rcClientNew;
GetClientRect(rcClientOld);
RepositionBars(AFX_IDW_CONTROLBAR_FIRST, AFX_IDW_CONTROLBAR_LAST, 0, reposQuery, rcClientNew);
//m_wndToolBar.ShowPane(FALSE, FALSE, TRUE); // Hide toolbar
RecalcLayout();
return 0;
}
OnCreate method updated:
int CMainFrame::OnToolBarCreate()
{
enter code here// TODO: Add your implementation code here.
if (m_wndToolBar)
{
m_wndOutput.AddStringStatusTab(_T("Error: Icon toolbar is already active, action cancelled"));
m_wndOutput.AddStringDebugTab(_T("Debug: MainFrame--Error: Icon toolbar is already active, action cancelled"));
return -1;
}
CMFCPopupMenu::SetForceMenuFocus(FALSE);
//CMDIChildWndEx::m_bEnableFloatingBars = TRUE;
// Create ToolBar toolbar
if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_ALIGN_TOP
| CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) ||
!m_wndToolBar.LoadToolBar(IDR_MAINFRAME))
{
TRACE0("Failed to Create Dialog ToolBar\n");
return -1;
}
m_wndMenuBar.EnableDocking(FALSE);
m_wndToolBar.EnableDocking(FALSE);
m_wndMenuBar.EnableDocking(CBRS_ALIGN_ANY);
m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
EnableDocking(CBRS_ALIGN_ANY);
DockPane(&m_wndMenuBar);
DockPane(&m_wndToolBar);
// DockPaneLeftOf(&m_wndToolBar);
CDockingManager::SetDockingMode(DT_SMART);
EnableAutoHidePanes(CBRS_ALIGN_ANY);
CRect rcClientOld;
CRect rcClientNew;
GetClientRect(rcClientOld);
RepositionBars(AFX_IDW_CONTROLBAR_FIRST, AFX_IDW_CONTROLBAR_LAST, 0, reposQuery, rcClientNew);
m_wndOutput.AddStringStatusTab(_T("I'm created 1 times"));
//m_wndToolBar.ResetAll();
RecalcLayout();
//m_wndToolBar.ShowPane(TRUE, FALSE, TRUE); // Show toolbar
return 0;
}
The images below:
Start from OnCreate with the panes properly "docked" mode
Destroyed ToolBar
ToolBar is switched from dock to float mode with Update 2 code. Ghost bars shown in the image. Trying to solve that issue.
Soooooo....anyone have any ideas on how I can solve this riddle?
Thanks!
Chris
As the title propose, I have an CMDIChildWndEx application(on VS2017, Windows 10 x64). On the ChildFrame, CMyView creates: (A) CMFCTabCtrl (Id=1), 2 CView derived classes: Lets say (B) CViewDerivedA object (Id=2) and (C) CViewDerivedB object (Id=3). The parent of A-C is the parent of CMyView. CMyView adds CDerivedViewA object as tab-0, and CViewDerivedB object as tab-1. CViewDerivedA handle MenuA of the menubar . But, when I open a MDI document, the menu is not enabled, until I switch to tab-1 & back to tab-0. I try the following code, but SetFocus() doesn't work:
// An application sends the WM_MDIACTIVATE message to a multiple-document interface (MDI)
// client window to instruct the client window to activate a different MDI child window.
void CMyChildFrame::OnMDIActivate(BOOL bActivate, CWnd* pActivateWnd, CWnd* pDeactivateWnd)
{
CMDIChildWndEx::OnMDIActivate(bActivate, pActivateWnd, pDeactivateWnd);
if (bActivate)
{
CMFCTabCtrl *pTabCtrl = (CMFCTabCtrl*) GetDlgItem(1);
if (pTabCtrl->GetActiveTab() == 0) // 0 - Silhouette tab, 1 - Hit List tab
{
// CWnd * pWnd = GetDlgItem(2);
// pWnd->SetFocus();
pTabCtrl->SetActiveTab(1);
pTabCtrl->SetActiveTab(0);
}
}
}
In any case, this solution seems to me not "clean", a "workaround". >>>> I assume that the proper way is to tell the pTabCtrl (Id=1) to SetFocus() on the active tab, as it does when I SetActiveTab() next & back. What is the way to make it properly?
I find the solution:
void CMyChildFrame::OnMDIActivate(BOOL bActivate, CWnd* pActivateWnd, CWnd* pDeactivateWnd)
{
CMDIChildWndEx::OnMDIActivate(bActivate, pActivateWnd, pDeactivateWnd);
if (bActivate)
{
CView * pView = (CView*)((CMFCTabCtrl*)GetDlgItem(1))->GetActiveWnd();
SetActiveView(pView);
}
}
I'm having the following code:
CMainFrame* pFrame = new CMainFrame;
if (!pFrame)
return FALSE;
m_pMainWnd = pFrame;
// create and load the frame with its resources
pFrame->LoadFrame(IDR_APP_MAINFRAME,
WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE, NULL,
NULL);
// The one and only window has been initialized, so show and update it
pFrame->ShowWindow(SW_SHOWMAXIMIZED);
The problem is, when I press <ALT>, the menu(IDR_APP_MAINFRAME) will popup.
How can I always hide the menu and do not response to presss?
I had heard this is due to an accelerator control in MFC, but I couldn't see the control in my project solution which is using VS2008..
In your CMainFrame override PreCreateWindow and destroy the menu. Try something like this:
BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if(cs.hMenu!=NULL)
{
::DestroyMenu(cs.hMenu);
cs.hMenu = NULL;
}
return CFrameWnd::PreCreateWindow(cs);
}