Chapter 9 -- Documents, Views, and the Single Document Interface

[Previous] [Next]

Chapter 9

In the early days of MFC, applications were architected in very much the same style as the sample programs in the first three chapters of this book. In MFC 1.0, an application had two principal components: an application object representing the application itself and a window object representing the application's window. The application object's primary duty was to create a window, and the window in turn processed messages. Other than the fact that it provided general-purpose classes such as CString and CTime to represent objects unrelated to Microsoft Windows, MFC was little more than a thin wrapper around the Windows API that grafted an object-oriented interface onto windows, dialog boxes, device contexts, and other objects already present in Windows in one form or another.

MFC 2.0 changed the way Windows applications are written by introducing the document/view architecture. In a document/view application, the application's data is represented by a document object and views of that data are represented by view objects. Documents and views work together to process the user's input and draw textual and graphical representations of the resulting data. MFC's CDocument class is the base class for document objects, and CView is the base class for view objects. The application's main window, whose behavior is modeled in MFC's CFrameWnd and CMDIFrameWnd classes, is no longer the focal point for message processing but serves primarily as a container for views, toolbars, status bars, and other user interface objects.

A programming model that separates documents from their views provides many benefits, not the least of which is that it more clearly defines the division of labor among software components and results in a higher degree of modularity. But the more compelling reason to take advantage of MFC's document/view architecture is that it simplifies the development process. Code to perform routine chores such as prompting the user to save unsaved data before a document is closed is provided for you by the framework. So is code to transform ordinary applications into Active Document servers, to save documents to disk and read them back, to simplify printing, and much more.

MFC supports two types of document/view applications. Single document interface (SDI) applications support just one open document at a time. Multiple document interface (MDI) applications permit two or more documents to be open concurrently and also support multiple views of a given document. The WordPad applet is an SDI application; Microsoft Word is an MDI application. The framework hides many of the differences between the two user interface models so that writing an MDI application is not much different than writing an SDI application, but today developers are discouraged from using the multiple document interface because the SDI model promotes a more document-centric user interface. If the user is to edit two documents simultaneously, Microsoft would prefer that each document be displayed in a separate instance of your application. This chapter therefore examines the document/view architecture with a decided emphasis on the single document interface. Everything that you learn here, however, applies to MDI applications as well, and for completeness we'll examine the multiple document interface as well as methods for supporting multiple views in SDI applications in Chapter 11.