Download demo SDI application - 26 Kb
Download demo MDI application - 28 Kb
Creating applications using the MFC document/view architecture can save time, can
help you create more structured programs, and can also help alleviate a lot of
tedious boilerplate coding that you may otherwise be forced to write. It can, however,
force you to structure your applications in a way that doesn't quite fit the problem
you are trying to solve (such as games), and it does also mean you are forced to carry the overhead
of using the MFC runtime libraries. If you are sure that your user will have the version
of MFC already installed, or you don't mind including it in a setup program, and you
don't mind an executable that is a touch larger than an equivalent win32/SDK version
then MFC can save you a lot of time.
The doc/view architecture that is mentioned a lot in MFC literature simply refers
to the practice of separating your appplications data storage and minipulation logic
from the data visualisation logic. Basically, you have a
class to load, manipulate and store your data, and a
CView derived class to
display the data. Your document and view classes (you can have multiple document and
multiple view classes within a single app) are linked together using internal MFC classes
by your main application's (
CWinApp derived) class, and physically managed
on the screen by a Main Frame (
In Single Document Interface (SDI) applications, there is one
class and and one view. Each time a document is loaded the view is cleared and redrawn
using the information in the new document. The view is essentially reused.
The image below shows a typical SDI application. The main window contains the
menu, toolbar, status bar, and the view window. The menus, toolbar, status bar are
created and owned by the
CFrameWnd class. You can create entire applications
without having to touch the frame class at all.
CView class has, as its display area, the dotted section shown in
the image. Everytime that area needs repainting the class'
will be called, and the view will be expected to query it's associated document so
it knows what to draw.
In Multiple Document Interface (MDI) applications there is one main frame per
application (in this case a
CMDIFrameWnd, and one
CMDIChildWnd derived child frame for each document.
Each time a new document is opened a new
CMDIChildWnd is created that
lives inside the main applications
CMDIFrameWnd window. The main frame window
contains and owns the menus, toolbars and status bar, and each
window contains a view window. When you switch between different child frames the
main frame automatically updates the menu and toolbars to match that associated with
the current view inside the child frame.
In Visual Studio .NET there is a third option that creates a new
each time a new document is opened. This option won't be covered here yet.
It's important to note that each view can only be associated with one document and one
frame window. A
CMDIFrameWnd window contains zero or more
windows, and each
CMDIChildWnd contains one
window. However, each document can have more than one view associated with it. A typical example
is the case of a splitter window that can be split to show two different views of the same
Creating an application
Creating an MFC doc/view application is very simple. Fire
up the AppWizard (File | New...) and follow along.
First we select the MFC AppWizard.
Choose either MDI or SDI (dialog based have been covered
elsewhere) and click Next until you hit step 4.
This step allows you to customise a bunch of stuff
including toolbars, menus, status bar and print preview. Check the boxes and you
get all this for free! One important step here is the "Advanced" button. This
allows you to specify a file extension that your application will open by
default - and which the Windows Shell will associate with your application
should the user double click on a file of that type.
Here I've simple entered "my" as my file extension. Once the program is compiled and
run for the first time, all .my files will have the icon specified by the
resource (the actual resource name will obviously change with the name of your application).
Continue clicking Next and you will come to the final step that allows you to choose the
type of view you want. MFC provides a ton of different
CView derived types to make life
easier, including HTML viewers, scrolling views, views that wrap common controls
and a dialog-type Form view.
Once the wizard has finished you have an application that can be compiled and run immediately.
It won't do anything useful, but in a way it already does a lot: toolbars, status bars, menu, printing
and print preview and file type registration. All that remains is for you to fill in the
details of your document (
Serialize will load and save documents,
will be called to create a new document), and your view (
OnDraw to do the drawing,
OnInitialUpdate for initialising variables when the view is first created).
To customise the menus, icons and toolbars simply use the
resource editors provided with Visual Studio. Life doesn't get any easier.
For further tutorials, check out
Chris is the Co-founder, Administrator, Architect, Chief Editor and Shameless Hack who wrote and runs The Code Project. He's been programming since 1988 while pretending to be, in various guises, an astrophysicist, mathematician, physicist, hydrologist, geomorphologist, defence intelligence researcher and then, when all that got a bit rough on the nerves, a web developer. He is a Microsoft Visual C++ MVP both globally and for Canada locally.
His programming experience includes C/C++, C#, SQL, MFC, ASP, ASP.NET, and far, far too much FORTRAN. He has worked on PocketPCs, AIX mainframes, Sun workstations, and a CRAY YMP C90 behemoth but finds notebooks take up less desk space.
He dodges, he weaves, and he never gets enough sleep. He is kind to small animals.
Chris was born and bred in Australia but splits his time between Toronto and Melbourne, depending on the weather. For relaxation he is into road cycling, snowboarding, rock climbing, and storm chasing.