Message Maps
Message maps are MFC's alternative to a manually written WndProc switch statement: DECLARE_MESSAGE_MAP() in a class header declares the plumbing, and BEGIN_MESSAGE_MAP/END_MESSAGE_MAP in the .cpp file builds a static table pairing a Windows message or command ID with a handler member function, which CWnd::WindowProc (via AfxWndProc and OnWndMsg) walks at runtime — including up the class hierarchy — to find and invoke the right handler without you writing message-dispatch code by hand.
Cricket analogy: It's like a fielding chart pinned to the dressing-room wall mapping each specific delivery type to a named fielder's position, so the captain doesn't re-brief placements verbally before every single ball.
Anatomy of BEGIN_MESSAGE_MAP
Inside BEGIN_MESSAGE_MAP(CMyWnd, CWnd), macros like ON_WM_PAINT(), ON_WM_LBUTTONDOWN(), and ON_COMMAND(ID_FILE_OPEN, &CMyWnd::OnFileOpen) each expand to an entry in a static AFX_MSGMAP_ENTRY array recording the message ID, any wParam/lParam filtering needed, and a pointer-to-member-function cast; the second parameter to BEGIN_MESSAGE_MAP names the immediate base class, which is how OnWndMsg walks up through CWnd::GetMessageMap() to check base-class maps when the derived class's own table has no matching entry for a given message.
Cricket analogy: It's like a bowling attack's strategy sheet listing named deliveries — a slower ball, a yorker, a bouncer — each tied to a specific match situation, with a fallback to the standard length ball if none of the special cases apply.
Command Routing and ON_UPDATE_COMMAND_UI
How Commands Reach the Right Handler
Beyond raw window messages, MFC message maps also route WM_COMMAND notifications (menu items, toolbar buttons, accelerator keys) through a chain of command targets — the view, then the document, then the document template, then the frame, then the application — via CCmdTarget::OnCmdMsg(), so a single ID_EDIT_COPY command can be handled wherever it makes most sense in a document/view architecture; ON_UPDATE_COMMAND_UI(ID_EDIT_COPY, &CMyView::OnUpdateEditCopy) similarly maps a UI-update pseudo-message, letting a handler enable/disable or check a menu item or toolbar button just before it's displayed.
Cricket analogy: It's like a run-out appeal being referred first to the on-field umpire, then to the third umpire, then finally to the match referee if still unresolved, each link in the chain getting a chance to make the call.
// MyView.h
class CMyView : public CView
{
protected:
afx_msg void OnEditCopy();
afx_msg void OnUpdateEditCopy(CCmdUI* pCmdUI);
afx_msg void OnLButtonDown(UINT nFlags, CPoint point);
DECLARE_MESSAGE_MAP()
};
// MyView.cpp
BEGIN_MESSAGE_MAP(CMyView, CView)
ON_COMMAND(ID_EDIT_COPY, &CMyView::OnEditCopy)
ON_UPDATE_COMMAND_UI(ID_EDIT_COPY, &CMyView::OnUpdateEditCopy)
ON_WM_LBUTTONDOWN()
END_MESSAGE_MAP()
void CMyView::OnEditCopy()
{
// ... copy current selection to clipboard
}
void CMyView::OnUpdateEditCopy(CCmdUI* pCmdUI)
{
pCmdUI->Enable(HasSelection()); // greys out the menu item/toolbar button
}
void CMyView::OnLButtonDown(UINT nFlags, CPoint point)
{
CView::OnLButtonDown(nFlags, point); // let the base class run its logic too
}
ON_UPDATE_COMMAND_UI handlers run automatically just before a menu is displayed or an idle cycle occurs, so you should keep them fast and side-effect free — they exist purely to set CCmdUI state like Enable(), SetCheck(), or SetText().
A message-map entry only takes effect if DECLARE_MESSAGE_MAP() is present in the class declaration and BEGIN_MESSAGE_MAP/END_MESSAGE_MAP correctly names the immediate base class as the second argument. Naming the wrong base class breaks the fallback chain that OnWndMsg relies on, silently dropping messages that should have been handled by an ancestor class.
- Message maps replace a hand-written WndProc switch statement with a static table of message-to-handler entries.
- DECLARE_MESSAGE_MAP() and BEGIN_MESSAGE_MAP/END_MESSAGE_MAP work together to build and register that table.
- ON_WM_* macros handle raw Windows messages; ON_COMMAND handles WM_COMMAND from menus/toolbars/accelerators.
- OnWndMsg walks up the class hierarchy via GetMessageMap() when a derived class's map has no matching entry.
- Command routing in document/view apps passes WM_COMMAND through view, document, frame, and app in sequence.
- ON_UPDATE_COMMAND_UI maps a UI-update pseudo-message used to enable/disable or check menu and toolbar items.
- The base class named in BEGIN_MESSAGE_MAP must be the true immediate base, or message fallback breaks silently.
Practice what you learned
1. What does BEGIN_MESSAGE_MAP/END_MESSAGE_MAP produce at compile time?
2. What is the purpose of the second parameter passed to BEGIN_MESSAGE_MAP(CMyView, CView)?
3. Which macro is used to handle a WM_COMMAND from a menu item or toolbar button?
4. What is the role of ON_UPDATE_COMMAND_UI?
5. In a document/view application, in what general order does a WM_COMMAND typically get routed?
Was this page helpful?
You May Also Like
Creating Windows with MFC
How MFC's CWnd/CFrameWnd hierarchy and CWinApp::InitInstance replace manual Win32 window registration and message-loop code.
Dialog-Based Applications
How MFC's dialog-based application template uses DoModal and DDX/DDV to build a self-contained UI without a document/view frame.
MFC Controls Overview
A tour of MFC's C++ wrapper classes for Windows common controls, how to bind them via DDX_Control, and practical examples with CListCtrl and CComboBox.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics