100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
C++

MFC Quick Reference

A condensed lookup of MFC's core class hierarchy, message map macros, and common string/collection/resource idioms.

Practical MFCBeginner8 min readJul 10, 2026
Analogies

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.

cpp
// 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

Was this page helpful?

Topics covered

#MFCMicrosoftFoundationClassesStudyNotes#MicrosoftTechnologies#MFCQuickReference#MFC#Quick#Reference#Core#StudyNotes#SkillVeris#ExamPrep