Dewsoft Frontpage Tutorials

Lesson - 4:Documents and Views
4.5 - Document Templates, Views, and Frame Windows
Because you’ve been working with AppWizard-generated applications in this Unit, you’ve taken for granted a lot of what goes on in the background of an MFC document/view program. That is, much of the code that enables the frame window (your application’s main window), the document, and the view window to work together is automatically generated by AppWizard and manipulated by MFC. For example, if you look at the InitInstance() method of the Rectangles application’s CRecsApp class, you see (among other things) the lines shown in Listing 4.6. Listing 4.6 RECS.CPP—Initializing an Application’s Document CSingleDocTemplate* pDocTemplate; pDocTemplate = new CSingleDocTemplate( IDR_MAINFRAME, RUNTIME_CLASS(CRecsDoc), RUNTIME_CLASS(CMainFrame), RUNTIME_CLASS(CRecsView)); AddDocTemplate(pDocTemplate); In Listing 4.6, you discover one secret that makes the document/view system work. In that code, the program creates a document-template object. These document templates have nothing to do with C++ templates. A document template is an older concept, named before C++ templates were implemented by Microsoft, that pulls together the following objects: A resource ID identifying a menu resource—IDR_MAINFRAME in this case A document class—CRecsDoc in this case A frame window class—always CMainFrame A view class—CRecsView in this case Notice that you are not passing an object or a pointer to an object. You are passing the name of the class to a macro called RUNTIME_CLASS. It enables the framework to create instances of a class at runtime, which the application object must be able to do in a program that uses the document/view architecture. In order for this macro to work, the classes that will be created dynamically must be declared and implemented as such. To do this, the class must have the DECLARE_DYNCREATE macro in its declaration (in the header file) and the IMPLEMENT_DYNCREATE macro in its implementation. AppWizard takes care of this for you. For example, if you look at the header file for the Rectangles application’s CMainFrame class, you see the following line near the top of the class’s declaration: DECLARE_DYNCREATE(CMainFrame) As you can see, the DECLARE_DYNCREATE macro requires the class’s name as its single argument. Now, if you look near the top of CMainFrame’s implementation file (MAINFRM.CPP), you see this line: IMPLEMENT_DYNCREATE(CMainFrame, CFrameWnd) The IMPLEMENT_DYNCREATE macro requires as arguments the name of the class and the name of the base class. If you explore the application’s source code further, you find that the document and view classes also contain the DECLARE_DYNCREATE and IMPLEMENT_DYNCREATE macros. If you haven’t heard of frame windows before, you should know that they contain all the windows involved in the applications—this means control bars as well as views. They also route messages and commands to views and documents. The last line of Listing 4.6 calls AddDocTemplate() to pass the object on to the application object, CRecsApp, which keeps a list of documents. AddDocTemplate() adds this document to this list and uses the document template to create the document object, the frame, and the view window. Because this is a Single Document Interface, a single document template (CSingleDocTemplate) is created. Multiple Document Interface applications use one CMultiDocTemplate object for each kind of document they support. For example, a spreadsheet program might have two kinds of documents: tables and graphs. Each would have its own view and its own set of menus. Two instances of CMultiDocTemplate would be created in InitInstance(), each pulling together the menu, document, and view that belong together. If you’ve ever seen the menus in a program change as you switched from one view or document to another, you know how you can achieve the same effect: Simply associate them with different menu resource IDs as you build the document templates.

	Next>>