SDI vs MDI Programs

An SDI program is a Single Document Interface program, meaning that the program will only have one document open at a time. An MDI program is a Multiple Document Interface, where the program may have several documents open simoultaneously.

In either case, it is possible to have several views for a specific document type, and it is also possible to have several document types in a single program. An SDI program with several document types will only permit one file to be open at a time.

The SDI format is the 'typical' or default program type, though MFC and AppWizard make it very easy to create and write either. In Win16, the MDI was toted by Microsoft as the preferred method of writting programs, but in Win32, they have decided that SDI programs should be the norm.


Dialog Applications
A Dialog Based application (the third option in your first AppWizard dialog for a new project) is a program that doesn't have any document, and is similar to the CFormView in that you can easily place onstrols on the main form. You can attach a menu to the dialog with the dialog properties in the dialog editor. Dialog applications do not normally have a File menu choice with Save or Open options.

Classes created for an SDI program
The following classes are created for a skeleton SDI program, by AppWizard:
Class Derived from Description
CAbout CDialog Implements the About Box in the Help menu choice.
CMainFrame CFrameWnd The main frame for the program.
CappApp CWinApp Implements application functionality.
CappDoc CDocument Implements data handling for application.
CappView Depends* Implements user interface for application.

*- The base class depends on the user's AppWizard selection.

 

Classes created for an MDI program
The following classes are created for a skeleton MDI program, by AppWizard:
Class Derived from Description
CAbout CDialog Implements the About Box in the Help menu choice.
CChildFrame CMDIChildWnd Implements the MDI child window, which holds a View object.
CMainFrame CMDIFrameWnd Program's main frame, implements the MDI child containment.
CappApp CWinApp Implements application functionality.
CappDoc CDocument Implements data handling for application.
CappView Depends* Implements user interface for application.

*- The base class depends on the user's AppWizard selection.


CMDIFrameWnd and CFrameWnd

MDI Menus
Each MDI child can have it's own menu that replaces the mainframe's menu (if no MDI child is open, then the mainframe menu is displayed). When an MDI application is created, AppWizard creates two menu resources:

IDR_MAINFRAME The mainframe's menu
IDR_appTYPE The MDI child's menu



The association between an MDI child and it's menu is based upon the re-use of the same #define symbol for it's resource string and menu. For example, in the skeleton app, you will find a string resource ID of IDR_appTYPE and a menu ID of IDR_appTYPE (same ID). If you look in the InitInstance function of your CWinApp-derived application class, you will find the creation of a CMultiDocTemplate object like:

pDocTemplate = new CMultiDocTemplate(
	IDR_appTYPE,
	RUNTIME_CLASS(CappDoc),
	RUNTIME_CLASS(CChildFrame), // custom MDI child frame
	RUNTIME_CLASS(CappView));
AddDocTemplate(pDocTemplate);

The constructor for this new object uses the IDR_appTYPE ID to identify the resource string and menu for the new document-view pair. It also specifies a document-view pair, and the type of MDI child window that the view should be created in. The resource string for a document defines things like the basic document title, it's registered type name, filter extension, and so on. Things found in the 'Advanced' button of the 4th dialog of AppWizard.

When an MFC MDI program selects an MDI child window, the menu for that menu is automatically loaded into the menu bar. The child's menu replaces (not appends) the mainframe menu.


CDocTemplate and CMultiDocTemplate
The CDocTemplate and CMultiDocTemplate are classes that are responsible for associating a document type with a view type. If you were to create new view types or document types, you would perform the following basic steps:

  1. Create the new document or view class
  2. Dynamically create a new CDocTemplate or CMultiDocTemplate, in the InitInstance function (like above)*
  3. Call the AddDocTemplate with the new object.


* - This is where you can specify the resource string, menu, document type and view type. The document and/or view type may be a new type.


Now, when a new document is created, a dialog box will appear to prompt for you for which type of document to create. When the new document is created, a view will also be created, the one specified in step 2 from above.

OnNewDocument
The OnNewDocument for an SDI program is called to clear out the contents of a document (like a constructor) when the user selects the File/New menu choice. For an MDI program, this function is never called, instead a new CDocument object is created.


Document Resource Strings
A resource string for a document is actually several strings in one, separated by a \n character. If any string is blank, the \n still appears. There are 7 sub-strings here are the options selected in the Advanced button in the 4th dialog of AppWizard's create-project wizard. These 7 strings are (in order): Window Title, Document Name, New filename, Filter name, Filter Extension, Registered file type ID, and Registered File Type Name. See the CDocTemplate::GetDocString function for more details.

You can change any of these values after the string is created, by editing the string in the String Table Resource Editor