MFC Quick Reference
This quick reference collects the class hierarchy, message map macros, and resource-cleanup idioms an MFC developer reaches for daily, condensed for fast lookup rather than deep explanation. It assumes familiarity with the concepts covered elsewhere in this course and is meant to sit open in a second monitor while coding, the way a cheat sheet for a well-known API saves you from repeatedly searching documentation for syntax you've already learned once.
Cricket analogy: A quick reference sheet is like a fielding-position chart a captain glances at between overs — not for learning the game, but for fast recall of a setup they've already mastered.
Core Class Hierarchy and Message Map Macros
The MFC class hierarchy roots almost everything in CObject, which provides RTTI (DECLARE_DYNAMIC/DECLARE_DYNCREATE), serialization (Serialize()), and debug dumping (Dump()); CCmdTarget adds message-routing capability on top of that, and CWnd derives from CCmdTarget to wrap an HWND, from which CFrameWnd, CView, CDialog, and all standard controls (CButton, CEdit, CListCtrl, and so on) ultimately descend. The message map macros — BEGIN_MESSAGE_MAP(theClass, baseClass), ON_MESSAGE(msg, handler), ON_COMMAND(id, handler), ON_UPDATE_COMMAND_UI(id, handler), ON_NOTIFY(code, id, handler), and END_MESSAGE_MAP() — connect specific Windows messages, command IDs, or control notification codes to member function handlers, and every class using them needs a matching DECLARE_MESSAGE_MAP() in its header.
Cricket analogy: The CObject-to-CWnd hierarchy is like the fielding hierarchy from captain down to individual fielders — each layer adds specific responsibility (RTTI, message routing, HWND ownership) the way a captain, then bowler, then fielder each add their own layer of decision-making.
// Quick-reference skeleton: minimal CView-derived class with a message map
class CMyView : public CView
{
protected:
DECLARE_DYNCREATE(CMyView)
DECLARE_MESSAGE_MAP()
public:
afx_msg void OnSize(UINT nType, int cx, int cy);
afx_msg void OnFileNewCommand();
afx_msg void OnUpdateFileNewCommand(CCmdUI* pCmdUI);
afx_msg void OnPaint();
};
IMPLEMENT_DYNCREATE(CMyView, CView)
BEGIN_MESSAGE_MAP(CMyView, CView)
ON_WM_SIZE()
ON_WM_PAINT()
ON_COMMAND(ID_FILE_NEW, &CMyView::OnFileNewCommand)
ON_UPDATE_COMMAND_UI(ID_FILE_NEW, &CMyView::OnUpdateFileNewCommand)
END_MESSAGE_MAP()
void CMyView::OnSize(UINT nType, int cx, int cy)
{
CView::OnSize(nType, cx, cy); // always call base first
Invalidate();
}Frequently Used Idioms and String/Collection Classes
CString is MFC's reference-counted, copy-on-write string class supporting both ANSI and Unicode builds transparently via the TCHAR/_T() macro layer, with Format() for printf-style construction and GetString() (or implicit conversion via operator LPCTSTR) for interop with Win32 APIs expecting raw pointers. For collections, older MFC code favors CArray, CList, and CMap templates (e.g. CArray<CPoint, CPoint&>), while modern MFC code increasingly mixes in standard library containers like std::vector directly, since MFC's collection templates and STL containers can coexist in the same codebase without conflict. For resource cleanup, the standard idiom is to wrap raw GDI/HANDLE-based resources in their MFC classes (CBitmap, CBrush, CFont, CPen, CGdiObject) and let their destructors call the matching Delete*() function automatically when they go out of scope, provided the object was not left selected into a DC.
Cricket analogy: CString's copy-on-write behavior is like a scorebook that's only re-copied when someone actually edits an entry — multiple people can read the same scorebook page cheaply until an edit forces a fresh copy.
Prefer CString::Format() over manual sprintf-style buffer manipulation, and prefer CArray/CList only when interoperating with existing MFC APIs that expect them; for new internal logic, std::vector and std::wstring integrate cleanly with CString via GetString()/operator LPCTSTR and are generally easier to unit test outside the MFC framework.
- CObject provides RTTI, serialization, and debug dumping; CCmdTarget adds message routing; CWnd wraps an HWND.
- Every message-map-using class needs both DECLARE_MESSAGE_MAP() in the header and BEGIN/END_MESSAGE_MAP() in the source file.
- ON_COMMAND pairs with ON_UPDATE_COMMAND_UI to keep menu/toolbar enabled-state in sync with command availability.
- CString is reference-counted and copy-on-write, transparently supporting ANSI/Unicode builds via TCHAR/_T().
- MFC collection templates (CArray, CList, CMap) and STL containers can coexist safely in the same codebase.
- GDI wrapper classes (CPen, CBrush, CFont, CBitmap) auto-delete on destruction only if not left selected into a DC.
- Always call the base class implementation first inside overridden handlers unless intentionally replacing default behavior.
Practice what you learned
1. Which MFC base class provides RTTI support via DECLARE_DYNAMIC and serialization via Serialize()?
2. What must accompany BEGIN_MESSAGE_MAP/END_MESSAGE_MAP in a class's source file?
3. What is the purpose of pairing ON_COMMAND with ON_UPDATE_COMMAND_UI for the same command ID?
4. What describes CString's memory behavior?
5. When does a GDI wrapper class like CPen fail to auto-delete its underlying handle on destruction?
Was this page helpful?
You May Also Like
MFC Common Pitfalls
The recurring mistakes MFC developers make with message maps, GDI resources, and the Document/View architecture, and how to avoid them.
Debugging MFC Applications
Practical techniques for diagnosing MFC bugs using TRACE, ASSERT_VALID, the debug heap, and Spy++ message inspection.
MFC Interview Questions
Common conceptual and debugging-style MFC interview questions, with the reasoning strong candidates use to answer them.
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