MFC Project Structure

Analogy categoryAnalogies

When Visual Studio's MFC Application Wizard generates a new document-based project, it produces a predictable set of files: an App class pair (CMyApp/MyApp.h/.cpp) derived from CWinApp, a document class pair derived from CDocument, a view class pair derived from CView, a main frame class pair derived from CFrameWnd or CMDIFrameWnd, a resource script (.rc) with matching resource.h, and a precompiled-header pair (pch.h/pch.cpp, formerly stdafx.h/stdafx.cpp) that speeds up compilation. Recognizing this layout at a glance - which pair of files implements which role in the Document/View architecture - is what lets a developer navigate an unfamiliar MFC codebase quickly instead of hunting blindly through dozens of similarly named files.

🏏

Cricket analogy: The Wizard's predictable file layout is like a scorecard's standardized sections (batting, bowling, fall of wickets) - once you know the format, you can find any statistic in any match's scorecard instantly, the way an MFC developer can find OnDraw() in any generated project.

Generated Source Files

The App class (typically named CMyProjectApp) overrides InitInstance() and is where the Wizard registers the document template; the Document class (CMyProjectDoc) holds the data and a Serialize() stub ready to fill in; the View class (CMyProjectView) has an OnDraw() stub ready for rendering logic; and MainFrm.h/.cpp defines CMainFrame, the top-level CFrameWnd-derived window that hosts the menu, toolbar, and status bar created via CreateEx(), LoadFrame(), and the OnCreateClient() family of overridable behaviors. A project using the Multiple Document Interface additionally generates a CChildFrame class, since in MDI each open document gets its own child frame window nested inside the single main frame.

🏏

Cricket analogy: CMainFrame hosting the menu, toolbar, and status bar is like a stadium's main stand housing the scoreboard, the commentary box, and the giant screen all under one roof, coordinating the whole spectator experience for the match.

Resource and Configuration Files

The .rc resource script defines every menu, dialog template, toolbar bitmap, string table entry, and icon, edited visually through Visual Studio's Resource View but stored as a text-based script that can, in a pinch, be hand-edited or diffed in source control; resource.h contains the matching #define constants (like #define ID_FILE_OPEN 32771) that both the .rc file and the C++ code reference by name. Build configuration - Debug versus Release, and whether MFC is linked as a shared DLL or statically into the executable - is set in the project's Properties pages under General > MFC of Use, and this choice affects both binary size (a statically linked Release build has no external MFC DLL dependency but is larger) and whether the target machine needs the redistributable MFC runtime DLLs installed.

🏏

Cricket analogy: resource.h's #define constants matching .rc entries is like a scorecard's numbered jersey list matching the team sheet exactly - both documents must agree on which number belongs to which player, or confusion follows during the match.

text

MyMfcApp/
├── MyMfcApp.h / MyMfcApp.cpp      // CMyMfcAppApp : public CWinApp
├── MyMfcAppDoc.h / .cpp           // CMyMfcAppDoc : public CDocument
├── MyMfcAppView.h / .cpp          // CMyMfcAppView : public CView
├── MainFrm.h / .cpp               // CMainFrame : public CFrameWnd
├── ChildFrm.h / .cpp              // CChildFrame (MDI projects only)
├── MyMfcApp.rc                    // menus, dialogs, toolbars, strings, icons
├── resource.h                     // #define ID_FILE_OPEN 32771, etc.
├── pch.h / pch.cpp                // precompiled header (formerly stdafx.h/.cpp)
├── res/                           // .ico, .bmp, .cur binary resource assets
└── MyMfcApp.vcxproj               // MSBuild project + Debug/Release configs

In Visual Studio's Project Properties, General > MFC of Use offers 'Use MFC in a Shared DLL' or 'Use MFC in a Static Library.' Choosing the shared DLL option produces a much smaller executable but requires the target machine to have the matching Visual C++ MFC redistributable installed.

Navigating an Unfamiliar MFC Project

The fastest way to orient yourself in an existing MFC codebase is to open the .rc file in Resource View first to see what menus, dialogs, and toolbars actually exist, then find the App class's InitInstance() to see which document template (and therefore which document/view/frame triplet) is registered for each document type, then read that document class's Serialize() to understand the actual data model before diving into the view's OnDraw() and message-map handlers. Class View and the 'Go To Definition' / 'Find All References' commands in Visual Studio are especially valuable here since MFC's message maps connect a resource ID to a handler function indirectly through macros rather than a direct, textually obvious call.

🏏

Cricket analogy: Starting from the .rc file's menus before diving into code is like a new commentator first reading the day's official team sheets and pitch report before calling the match, establishing the overall shape before following individual deliveries.

Because BEGIN_MESSAGE_MAP/END_MESSAGE_MAP entries connect a resource ID to a handler function through macro expansion, a plain text search for 'ID_FILE_OPEN' will find the .rc definition and the message map entry, but not necessarily every place the command is enabled/disabled via an ON_UPDATE_COMMAND_UI handler - check for both when tracing a menu item's full behavior.

The MFC Application Wizard generates App, Document, View, and MainFrame class pairs plus a resource script.
The App class overrides InitInstance() and registers the document template there.
The .rc resource file defines menus, dialogs, toolbars, and strings, paired with numeric IDs in resource.h.
pch.h/pch.cpp (formerly stdafx.h/.cpp) implement the precompiled header that speeds up compilation.
MDI projects additionally generate a CChildFrame class, one per open document window.
Build configuration controls Debug vs Release and whether MFC links as a shared DLL or statically.
The fastest way to explore an unfamiliar MFC project is .rc file, then InitInstance(), then Serialize(), then OnDraw().