The document view architecture was introduced in MFC 2.0. In this architecture the application's data is represented as a "document" object and the views of this data are represented as "view" objects. E.g. If you create an excel document what you see to get your job done i.e. cells, values, etc comprises the view and when you save this data it gets saved as a document. The various views of this document is as a table, graphs, bar charts, etc. The data is stored in a document object. The class representing the document object is CDocument. The sole purpose of this class is to manage an application's data. Views server two purposes: renders visual representation of data stored in document and translate the user's inputs into commands that operate on the data in the document. The class for view is CView. Thus the division of work in terms of data and view helps in work division, better productivity and reusability of code.

A dialog box is a window that pops up in response to user action to inform the user with a message. E.g. if the user does not save the document and exists the application the window pops up asking if he wants to save the document. This window is the dialog box. Modal Dialog: A modal dialog box disables the window to which it is assigned until the user dismisses the dialog box. E.g. The dialog that gets displayed with "yes"/"no"/"cancel" when you try to exit MS Word without saving the document is a modal dialog box.  A model dialog box is created by calling the doModal() function of the dialog class. This function does not return back control to the caller until the dialog is dismissed. E.g. CDialog dlg; dlg.doModal();  Modeless Dialog: A modeless dialog box is just the reverse of modal. It allows the user complete control of the application which owns it and the user can continue his work without closing the dialog. A modeless dialog box can be created using the Create () command of CDialog class. The Create() call returns as soon as the dialog box is created. Hence the control returns back to the caller and the user is able to continue using the application.

Common dialogs are those that appear so frequently in application programs and hence the have become a part of MFC library. MFC provides the common dialogs listed below: -         CFileDialog: File Open and File Save As dialog -         CPrintDialog: Print and Print Setup dialog -         CPageSetupDialog: Page setup dialog -         CFindReplaceDialog: File and replace dialog -         CColorDialog: Color dialog box -         CFontDialog: Dialog box to change font style, color, size, etc. A common dialog is invoked by filling in the fields of the data structure and then calling the doModal() of the dialog. When the dialog returns the user input values are populated in the respective fields of the data structure.E.g. Lets say we want to show the File Open dialog box. TCHAR filter [] = _T ("Text files (*.txt)|*.txt||"); //Specify a filer for the file type CFileDialog dlg(TRUE, _T("txt"), _T("*.txt"), OFN_FILEMUSTEXIST, filter);  If(dlg.doModal() == IDOK){//Get the user selected file namefilename = dlg.GetFileName();}

GDI is an acronym for Graphics Device Interface. The GDI allows you to draw on your windows. It is a device independent output model in the sense that the graphics code that you write for drawing will work on any video output which has a Windows driver.  In order to avoid one window interfering with another while drawing output on the screen GDI uses a mechanism called as device context to avoid this conflict. So when a window draws on a screen, printer or any other output device, it doesn't output pixels directly on the device. Instead it draws to a logical surface represented by a "device context" (DC). A DC is a data structure that has all information that GDI needs to know.  Before a Windows program draws anything on the screen it acquires a DC handle from the GDI and then passes this handle back to the GDI each time it calls the GDI output function. In MFC a DC encapsulates the GDI functions that a program uses to generate output. MFC's CDC class wraps a Windows device context and the GDI functions into one package. CPaintDC and CClientDC are subclasses of CDC and represent the different types of device contexts that windows applications use. E.g. CDC* pDC = GetDC(); //do some drawing Release (pDC);

In a multi threaded application each thread must coordinate its actions with other threads in the application. If two or more threads access a same resource then that resource needs to be synchronized so that all threads don't try to modify it at the same time. Windows supports four types of synchronization objects that can be used to synchronize the actions performed by concurrently running multiple threads.  -         Critical Sections -         Mutexes -         Events -         Semaphores Critical Section: These are used to serialize access to resources that are accessed by multiple threads. All the threads must belong to same process because critical sections won't work across process boundaries. CCriticalSection is a class and CCriticalSection::Lock locks a critical section and CCriticalSection::UnLock unlocks it.  E.g. CCriticalSection cs; //Thread T1 cs.Lock (); //access the shared resource cs.UnLock ();  /Thread T2 cs.Lock (); /access the shared resource Cs.Unlock (); Mutexes: Serves the same purpose as critical sections but can be used to synchronize threads running in same process or across processes. CMutex is its corresponding class.  Semaphores: They maintain resource counts representing the number of resources available. Locking a semaphore decrements resource count and unlocking increments it. A thread that tries to lock a semaphore with resource count 0 gets blocked until another thread unlocks the semaphore and increases the resource count. CSemaphore is a class representing semaphores.

Property sheets are tabbed dialog boxes containing pages that the user can switch with mouse clicks. They are a part of common library of windows just like dialog and other controls. E.g. when a user adds a schedules task it walks him through a wizard which is nothing but a property sheet. The functionality of property sheets is encapsulated in MFC classes of CPropertySheet and CPropertyPage. CPropertyPage represents a page in a property sheet and is a subclass of CDialog. Like dialog boxes property sheets can be modal or modeless. Use CPropertySheet::DoModal for modal and CPropertySheet::Create for a modeless property sheet.  There are four broad steps in creating a property page: 1. For each property page create a dialog template.   2. For the created dialog associate a class that derives from CPropertyPage.   3. Derive a property sheet class from CPropertySheet and create an object for each above created property pages.   4. Add the property page objects to the created property sheet using AddPage.   5. Call the doModal function of the property sheet to display it on the screen.