Unit II Notes
Unit II Notes
The Microsoft Foundation Class Library Application Framework Application framework An integrated collection of object-oriented software components that offers all that's needed for a generic An Application Framework vs. a Class Library - An application framework is a superset of a class library. - An ordinary library is an isolated set of classes designed to be incorporated into any program, but an application framework defines the structure of the program itself. Why Use the Application Framework? The MFC library is the C++ Microsoft Windows API. Application framework applications use a standard structure. Application framework applications are small and fast. The Visual C++ tools reduce coding drudgery The MFC library application framework is feature rich An Application Framework Example source code for the header and implementation files for our MYAPPapplication. MyApp.h header file for the MYAPP application.
{ public: virtual BOOL InitInstance(); }; // frame window class class CMyFrame : public CFrameWnd { public: CMyFrame(); protected: // "afx_msg" indicates that the next two functions are part // of the MFC library message dispatch system afx_msg void OnLButtonDown(UINT nFlags, CPoint point); afx_msg void OnPaint(); DECLARE_MESSAGE_MAP() };
MyApp.cpp - implementation file for the MYAPP application: #include <afxwin.h> // MFC library header file declares base classes #include "myapp.h" CMyApp theApp; // the one and only CMyApp object BOOL CMyApp::InitInstance() { m_pMainWnd = new CMyFrame();
ON_WM_PAINT()
END_MESSAGE_MAP()
CMyFrame::CMyFrame() { Create(NULL, "MYAPP Application"); } void CMyFrame::OnLButtonDown(UINT nFlags, CPoint point) { TRACE("Entering CMyFrame::OnLButtonDown - %lx, %d, %d\n", (long) nFlags, point.x, point.y); } void CMyFrame::OnPaint() { CPaintDC dc(this); dc.TextOut(0, 0, "Hello, world!"); }
The program elements: The WinMain function Windows requires your application to have a WinMain function. You don't see WinMain here because it's hidden inside the application framework. The CMyApp class An object of class CMyApp represents an application. The program defines a single global CMyApp object, theApp. The CWinApp base class determines most of theApp's behavior. Application startup When the user starts the application, Windows calls the application framework's built-in WinMain function, and WinMain looks for your globally constructed application object of a class derived from CWinApp. In a C++ program global objects are constructed before the main program is executed. The CMyApp::InitInstance member function When the WinMain function finds the application object, it calls the virtual
K.Karupusamy,L/MCA,Sasurie Academy of Engineering
InitInstance member function, which makes the calls needed to construct and display the application's main frame window. You must override InitInstance in your derived application class because the CWinApp base class doesn't know what kind of main frame window you want.
The CWinApp::Run member function The Run function is hidden in the base class, but it dispatches the application's messages to its windows, thus keeping the application running. WinMain calls Run after it calls InitInstance. The CMyFrame class An object of class CMyFrame represents the application's main frame window. When the constructor calls the Create member function of the base class CFrameWnd, Windows creates the actual window structure and the application framework links it to the C++ object. The ShowWindow and UpdateWindow functions, also member functions of the base class, must be called in order to display the window. The program elements: The CMyFrame::OnLButtonDown function MFC library's message-handling capability. The function invokes the MFC library TRACE macro to display a message in the debugging window. The CMyFrame::OnPaint function - The application framework calls this important mapped member function of class CMyFrame every time it's necessary to repaint the window: at the start of the program, when the user resizes the window, and when all or part of the window is newly exposed. - The CPaintDC statement relates to the Graphics Device Interface (GDI) and is explained in later chapters. The TextOut function displays "Hello, world!" Application shutdown - The user shuts down the application by closing the main frame window. - This action initiates a sequence of events, which ends with the destruction of the CMyFrame object, the exit from Run, the exit from WinMain, and the destruction of the CMyApp object.
K.Karupusamy,L/MCA,Sasurie Academy of Engineering
MFC Library Message Mapping The MFC library application framework doesn't use virtual functions for Windows messages. Instead, it uses macros to "map" specified messages to derived class member functions
Why the rejection of virtual functions? What about message handlers for menu command messages and messages from button clicks? An MFC message handler requires a function prototype, a function body, and an entry (macro invocation) in the message map. BEGIN_MESSAGE_MAP(CMyFrame, CFrameWnd) ON_WM_LBUTTONDOWN() ON_WM_PAINT() END_MESSAGE_MAP() Documents and Views Typically, MFC application will contain application and frame classes plus two other classes that represent the "document" and the "view." This document-view architecture is the core of the application framework The document-view architecture separates data from the user's view of the data. One obvious benefit is multiple views of the same data.
CHAPTER 2 The Visual C++ Components Microsoft Visual C++ is two complete Windows application development systems in one product. You can develop C-language Windows programs using only the Win32 API. You can use many Visual C++ tools, including the resource editors, to make lowlevel Win32 programming easier. Components:
The Project The Resource EditorsWorkspace ResourceView The C/C++ Compiler The Source Code Editor The Resource Compiler The Linker The Debugger AppWizard Classwizard What is a project? A project is a collection of interrelated source files that are compiled and linked to make up an executable Windows-based program or a DLL. Source files for each project are generally stored in a separate subdirectory. A project depends on many files outside the project subdirectory too, such as include files and library files.
A makefile stores compiler and linker options and expresses all the interrelationships among source files. A make program reads the makefile and then invokes the compiler, assembler, resource compiler, and linker to produce the final output, which is generally an executable file.
In a Visual C++ 6.0 project, there is no makefile (with an MAK extension) unless you tell the system to export one. 6 a DSP extension) serves the same purpose. A text-format project file (with
A separate text-format workspace file (with a DSW extension) has an entry for each project in the workspace. It's possible to have multiple projects in a workspace, but all the
Examples in this book have just one project per workspace. To work on an existing project, you tell Visual C++ to open the DSW file and then you can edit and build the project. VC++ Project Files
Visual C++ creates some intermediate files too File Extension APS BSC CLW DEP DSP *DSW *MAK NCB OPT PLG Description Supports ResourceView Browser information file Supports ClassWizard Dependency file Project file Workspace file External makefile Supports ClassView Holds workspace configuration Builds log file
The Resource Editors Workspace ResourceView Each project usually has one text-format resource script (RC) file that describes the project's menu, dialog, string, and accelerator resources. The RC file also has #include statements to bring in resources from other subdirectories. These resources include project-specific items, such as bitmap (BMP) and icon (ICO) files, and resources common to all Visual C++ programs, such as error message strings. Editing the RC file outside the resource editors is not recommended.
The resource editors can also process EXE and DLL files, so you can use the clipboard to "steal" resources, such as bitmaps and icons, from other Windows applications. The C/C++ Compiler The Visual C++ compiler can process both C source code and C++ source code. It determines the language by looking at the source code's filename extension. A C extension indicates C source code, and CPP or CXX indicates C++ source code.
The compiler is compliant with all ANSI standards, including the latest recommendations of a working group on C++ libraries, and has additional Microsoft extensions. Templates, exceptions, and runtime type identification (RTTI) are fully supported in Visual C++ version 6.0. The C++ Standard Template Library (STL) is also included, although it is not integrated into the MFC library.
Visual C++ 6.0 includes a sophisticated source code editor that supports many features such as dynamic syntax coloring, auto-tabbing, keyboard bindings The Resource Compiler
The Visual C++ resource compiler reads an ASCII resource script (RC) file from the resource editors and writes a binary RES file for the linker. The Linker
The linker reads the OBJ and RES files produced by the C/C++ compiler and the resource compiler, and it accesses LIB files for MFC code, runtime library code, and Windows code. It then writes the project's EXE file. The Debugger The Visual C++ debugger has been steadily improving, but it doesn't actually fix the bugs yet. The debugger works closely with Visual C++ to ensure that breakpoints are saved on disk.
AppWizard AppWizard is a code generator that creates a working skeleton of a Windows application with features, class names, and source code filenames that you specify through dialog boxes. AppWizard code is minimalist code; the functionality is inside the application framework base classes. AppWizard gets you started quickly with a new application. ClassWizard ClassWizard is a program (implemented as a DLL) that's accessible from Visual C++'s View menu. ClassWizard takes the drudgery out of maintaining Visual C++ class code.
K.Karupusamy,L/MCA,Sasurie Academy of Engineering
Need a new class, a new virtual function, or a new message-handler function? ClassWizard writes the prototypes, the function bodies, and (if necessary) the code to link the Windows message to the function. ClassWizard can update class code that you write, so you avoid the maintenance problems common to ordinary code generators. CHAPTER 3 Basic Event Handling, Mapping Modes, and a Scrolling View The Message Handler: void CMyView::OnLButtonDown(UINT nFlags, CPoint point) { // event processing code here } The Message Map: BEGIN_MESSAGE_MAP(CMyView, CView) ON_WM_LBUTTONDOWN() // entry specifically for OnLButtonDown // other message map entries END_MESSAGE_MAP() Finally, your class header file needs the statement DECLARE_MESSAGE_MAP() Invalid Rectangle Theory InvalidateRect triggers a Windows WM_PAINT message, which is mapped in the CView class to call to the virtual OnDraw function. If necessary, OnDraw can access the "invalid rectangle" parameter that was passed to InvalidateRect. Your OnDraw function could call the CDC member function GetClipBox to determine the invalid rectangle, and then it could avoid drawing objects outside it. OnDraw is being called not only in response to your InvalidateRect call but also when
K.Karupusamy,L/MCA,Sasurie Academy of Engineering
the user resizes or exposes the window. Thus, OnDraw is responsible for all drawing in a window, and it has to adapt to whatever invalid rectangle it gets. The Window's Client Area A window has a rectangular client area that excludes the border, caption bar, menu bar, and any toolbars. The CWnd member function GetClientRect supplies you with the client-area dimensions. Normally, you're not allowed to draw outside the client area, and most mouse messages are received only when the mouse cursor is in the client area.
CRect, CPoint, and CSize Arithmetic The CRect, CPoint, and CSize classes are derived from the Windows RECT, POINT, and SIZE structures, and thus they inherit public integer data members as follows: CRect left, top, right, bottom CPoint x, y CSize cx, cy
Dialog : Using Appwizard and Classwizard The Modal Dialog and Windows Common Controls The two kinds of dialogs are modal and modeless. The CDialog base class supports both modal and modeless dialogs Modal Dialog Box: The user cannot work elsewhere in the same application (more correctly, in the same user interface thread) until the dialog is closed. Example: Open File dialog Modeless Dialog The user can work in another window in the application while the dialog remains on the screen Example: Microsoft Word's Find and Replace dialog is a good example of a modeless dialog; you can edit your document while the dialog is open. Controls. A dialog contains a number of elements called controls. Dialog controls include edit controls, buttons, list boxes, combo boxes, static text, tree views, progress indicators, sliders, and so forth.
Programming a Modal Dialog 2. Use the dialog editor to create a dialog resource that contains various controls. -The dialog editor updates the project's resource script (RC) file to include your new dialog resource, and it updates the project's resource.h file with corresponding #define constants. 2. Use ClassWizard to create a dialog class that is derived from CDialog and attached to the resource created in step 1. -ClassWizard adds the associated code and header file to the Microsoft Visual C++ project. 3. Use ClassWizard to add data members, exchange functions, and validation functions to the dialog class. 4. Use ClassWizard to add message handlers for the dialog's buttons and other eventgenerating controls. 5. Write the code for special control initialization (in OnInitDialog) and for the message handlers. Be sure the CDialog virtual member function OnOK is called when the user closes the dialog (unless the user cancels the dialog). (Note: OnOK is called by default.) 6.Write the code in your view class to activate the dialog. This code consists of a call to your dialog class's constructor followed by a call to the DoModal dialog class member function. DoModal returns only when the user exits the dialog window. In the CPP file, the constructor implementation looks like this: CMyDialog::CMyDialog(CWnd* pParent /*=NULL*/) : CDialog(CMyDialog::IDD, pParent) { // initialization code here } The use of enum IDD decouples the CPP file from the resource IDs that are defined in the project's resource.h The Windows Common Dialogs Windows provides a group of standard user interface dialogs, and these are supported by the MFC library classes. All the common class, CCommonDialog. dialog classes are derived from a common base
Purpose Allows the user to select or create a color Allows the user to open or save a file
CFindReplaceDialog Allows the user to substitute one string for another CPageSetupDialog Allows the user to input page measurement parameters CFontDialog Allows the user to select a font from a list of available fonts CPrintDialog Allows the user to set up the printer and print a document Using the CFileDialog Class Directly The following code opens a file that the user has selected through the dialog: CFileDialog dlg(TRUE, "bmp", "*.bmp"); if (dlg.DoModal() == IDOK) { CFile file; VERIFY(file.Open(dlg.GetPathName(), CFile::modeRead)); } The first constructor parameter (TRUE) specifies that this object is a "File Open" dialog instead of a "File Save" dialog. The default file extension is bmp, and *.bmp appears first in the filename edit box. The CFileDialog::GetPathName function returns a CString object that contains the full pathname of the selected file. BITMAPS Windows bitmaps are arrays of bits mapped to display pixels. There are two kinds of Windows bitmaps: GDI bitmaps GDI bitmap objects are represented by the Microsoft Library version 6.0 and DIBs. Foundation Class (MFC)
Color Bitmaps and Monochrome Bitmaps Many color bitmaps are 16-color. A standard VGA board has four contiguous color planes, with 1 corresponding bit from each plane combining to represent a pixel. The 4-bit color values are set when the bitmap is created. With a standard VGA board, bitmap colors are limited to the standard 16 colors. Windows does not use dithered colors in bitmaps. A monochrome bitmap has only one plane. Each pixel is represented by a single bit that is either off (0) or on (1). The CDC::SetTextColor function sets the "off" display color, and SetBkColor sets the "on" color.
You can specify these pure colors individually with the Windows RGB macro.
Code to load a Bitmap void OnPaint() { CBitmap mybm; CPaintDC d(this); mybm.LoadBitmap(IDB_BITMAP1); CBrush mybrush; mybrush.CreatePatternBrush(&mybm); d.SelectObject(&mybrush); d.Rectangle(100,100,300,300); }
GDI Bitmaps There are two kinds of Windows bitmaps: GDI bitmaps and DIBs. GDI bitmap objects are represented by the Microsoft Foundation Class (MFC) Library version 6.0 CBitmap class. The GDI bitmap object has an associated Windows data structure, maintained inside the Windows GDI module, that is device-dependent. Your program can get a copy of the bitmap data, but the bit arrangement depends on the display hardware. GDI bitmaps can be freely transferred among programs on a single computer, but because of their device dependency, transferring bitmaps by disk or modem doesn't make sense. Device-Independent Bitmaps
Device-Independent Bitmaps DIBs offer many programming advantages over GDI bitmaps. Since a DIB carries its own color information, color palette management is easier. DIBs also make it easy to control gray shades when printing. Any computer running Windows can process DIBs, which are usually stored in BMP disk files or as a resource in your program's EXE or DLL file.
The wallpaper background on your monitor is read from a BMP file when you start Windows. The primary storage format for Microsoft Paint is the BMP file, and Visual C++ uses BMP files for toolbar buttons and other images. Other graphic interchange formats are available, such as TIFF, GIF, and JPEG, but only the DIB format is directly supported by the Win32 API.