Microsoft Visual C++ .NET Professional Projects - Premier Press

5.Override the InitInstance function and define the settings for your application. Here’s what needs to be done in the InitInstance function:

Create an instance of the window class of your application; here it is

MyWindow:

MyWindow *MywindowObject = new MyWindow;

MyWindowObject is the object of the MyWindow class and represents the current instance of the application.

Assign the window object that you created to the m_pMainWnd variable of the CWinApp class. m_pMainWnd always points to the main window of the application and thereby determines the lifetime of your application. This implies that only until the main window of the application is pointed to by m_pMainWnd, the application exists.

Invoke the ShowWindow function to display the window created. The ShowWindow function accepts the show state of the window, such as SW_SHOWNORMAL, that displays the window in the normal state (similar to the traditional window).

6. Instantiate the application class itself:

MyApp MyAppObject;

In this case, MyAppObject is the object pointing to the MyApp class.

The flowchart in Figure 2-7 depicts the sequence of events that occur after you execute an application, such as the sample application.

Type the code snippet preceding these steps and execute your application. Figure 2-8 displays the final output of the sample application.

Message Maps

You are now familiar with the classes that provide the foundation of your application. This section moves ahead to give you more details about messages and how to add the message-handling functionalities to your application.

From the earlier discussion, you know that Windows handles events by using message maps that handle the routing of messages to the appropriate message handlers. Taking this discussion further, messages are typically generated as a result of user-initiated actions. For example, when the user moves the mouse, Windows generates mouse-related messages; in this case, WM_MOUSEMOVE. In

END_MESSAGE_MAP. You use this macro to mark the end of the message map entries. The syntax for this macro is as follows:

END_MESSAGE_MAP()

ON_COMMAND. You use this macro to map the message handlers for all command messages, such as messages generated when the user chooses a menu option. For example, when the user chooses File, Save, you want to display a message. To do this, you have defined a message handler named Display. The message map entry corresponding to this will be the following:

ON_COMMAND(ID_SAVE, Display)

In the preceding code, the first parameter, ID_SAVE, is the ID of the menu option (which you define while designing the menu), and the second parameter, Display, is the message handler that will display the message.

CAUTION

Don’t place a semicolon at the end of DECLARE_MESSAGE_MAP(),

BEGIN_MESSAGE_MAP(), and other message map macros.

Create(NULL,”Example Window”);

MessageBox(“Created”);

The window class of the sample application has been designed to handle messages. Hence, the DECLARE_MESSAGE_MAP macro is placed at the end of the class declaration. After the declaration, the BEGIN_MESSAGE_MAP macro is placed. It accepts MyWindow, which is the name of the derived class, and CFrameWnd, which is the base class, as parameters indicating that MyWindow class will handle the messages. The ON_LBUTTON_DOWN() macro is used to trap the WM_LBUTTONDOWN message, which will be generated once the user clicks the left button. Corresponding to this message, OnLButtonDown is the message handler. To summarize the working of this application:

1.The user clicks the left mouse button, which results in the WM_LBUTTONDOWN message.

2.The Run member function of the CWinApp class retrieves the message and directs it to the window class.

3.Control passes to the MyWindow class because it has the message map entries.

4.The ON_LBUTTON_DOWN() macro is executed, which further invokes the

OnLbuttonDown message handler.

5.The MessageBox function within the OnLButtonDown message handler displays the given message.

To execute this application, you can edit the previous application that you created.

You now know how to handle messages in your application. You will learn more about message handling in the subsequent chapters. Moving ahead, the next section explains the second most predominant feature of Windows programming, device independence, and how MFC supports it.

Device Independence

In this world of graphical user interface (GUI) operating systems, support of graphics is one of the main features that any programming model should cater to. Of course, Windows, the first GUI operating system, is no exception. In fact, the use of graphics is one of the core components of Windows programming, because in Windows, every output, whether it is text, an image, or a picture, is “painted” to the screen as graphics. This is implemented using the Graphical Device Interface (GDI), which provides the basic functionalities of drawing. (GDI provides predefined set of GDI objects, such as pens and brushes, which enable you to render drawings on any device. You will learn more about GDI objects in one of the

subsequent sections.) GDI acts as the interface between the application and the actual output device, whether a screen or a printer, and thus insulates the application from writing to the output device directly.

The GDI takes care of rendering the output to the appropriate output device by interacting with the device drivers. Figure 2-9 depicts the difference between DOS programs handling devices and Windows programs handling devices.

Screen

Printer

Screen

Printer

FIGURE 2-9 Device handling in DOS and Windows

Am I getting closer to the concept of device independence? Yes, I’m almost there. The only other question is how does GDI take care of device independence? It does this by using device contexts.

Device Contexts

A device context is a data structure that is a logical representation of the physical devices, such as a VDU or a printer. A device context contains the drawing attributes, such as colors, and drawing tools (GDI objects), such as pens and brushes, of the device. Besides handling physical devices, a device context can also handle logical devices, such as metafiles. A metafile stores the pictures in a device-inde- pendent form, which you can use to store and reproduce pictures later. Metafiles are similar to the disk files used to store data.

MFC provides you with a set of classes to handle a device context. Figure 2-10 displays the hierarchy of MFC device context classes, which are described next:

CObject

CDC

CClient

CPaintDC

CWindowDC

CMetaFileDC

FIGURE 2-10 The MFC device context classes

CDC. The CDC class is the base class for all other device context classes. This class provides member functions to work with device contexts, such as a VDU or a printer, and to work with the client area of a window.

Besides the member functions for handling device contexts, the CDC class also provides member functions to handle GDI objects, functions for retrieving and setting drawing attributes, and functions for drawing. As with any other classes, to work with the CDC class, you first need to construct the object and then call the appropriate member functions to draw onto the device contexts.

CClientDC. The CClientDC class, which is one of the derived classes of CDC, is used to work with the client areas of a window. This class provides member functions that you can use to draw onto the client area of a window. The CClientDC class uses the GetDC function to construct a device context and uses the ReleaseDC function to release it.

CPaintDC. The CPaintDC class, derived from the CDC class, handles the processing of the WM_PAINT message. Recall the use of BeginPaint and EndPaint API functions to paint the window of an application. The