MFC与Windows程序设计：第二版英文版精要指南

4星 · 超过85%的资源需积分: 10 75 浏览量更新于2024-07-22 收藏 7.75MB PDF 举报

《MFC.Windows程序设计.第二版英文版》是一本深度讲解Microsoft Foundation Classes (MFC)与Windows应用程序开发的权威教材。该书针对Windows编程模型进行了详细介绍，并逐步引导读者掌握MFC的基础知识和高级特性。在第一部分“Windows和MFC基础”中，作者首先通过“Hello, MFC”章节让读者对MFC有初步了解，介绍了Windows编程模型，包括窗口、消息传递等核心概念。接着，作者通过实际操作指导读者创建第一个MFC应用，展示如何利用MFC简化窗口绘制过程，如使用Windows GDI进行图形界面设计。第二章进一步深入探讨了鼠标和键盘输入处理，教会读者如何获取并处理用户的输入，提供了“Visual KB Application”的实例来演示这一技术。菜单设计是后续章节的重要部分，从基本菜单功能到高级菜单管理和控制，如“Shapes Application”和“Colors Application”，通过实例让读者掌握菜单操作的灵活性。第三部分涉及MFC的集合类，包括数组、列表、映射和类型指针类，这些数据结构在管理窗口元素和数据时非常实用。随后，文件I/O和序列化功能被详细解析，包括CFile类的应用以及CArchive类在保存和加载数据方面的用法。第四部分重点关注控件，分为经典控件和高级控件编程，展示了如何使用MFC处理不同类型的控件，如按钮、文本框等，并介绍了对话框和属性表的使用。对于模态对话框和非模态对话框的区别，以及如何将对话框作为主窗口的操作都有详尽的讲解。这本书不仅涵盖了Windows程序设计的基本要素，而且深入浅出地展示了MFC框架的强大功能，适合于希望提升Windows应用程序开发技能的开发者和学习者，无论是初学者还是经验丰富的程序员都能从中获益良多。通过阅读和实践本书中的示例，读者能够扎实地建立起Windows平台下高效开发应用程序的能力。

It should do so without imposing undue overhead on the system or unnecessarily adding to an

application's memory requirements.

The first goal was accomplished by writing classes to encapsulate windows, dialog boxes, and other objects

and by including key virtual functions that can be overridden to alter the behavior of derived classes. The

second goal required the architects of MFC to make some choices early on about how windows, menus,

and other objects would be wrapped by MFC classes such as CWnd and CMenu. Efficient use of memory

was important then and it's important today, because nobody likes a class library that produces bloated

code.

One of the ways in which the designers of MFC minimized the overhead added by the class library is

manifested in the relationship between MFC objects and Windows objects. In Windows, information about

the characteristics and current state of a window is stored in memory owned by the operating system. This

information is hidden from applications, which deal exclusively with window handles, or HWNDs. Rather

than duplicate all the information associated with an HWND in the data members of the CWnd class, MFC

wraps a window in a CWnd by storing the HWND in a public CWnd data member named m_hWnd. As a

rule, if Windows exposes an object through a handle of some type, the corresponding MFC class will

contain a data member for that handle. This knowledge can be useful if you want to call an API function

that requires a handle but you have, say, a CWnd or CWnd pointer instead of an HWND.

The Document/View Architecture

The cornerstone of MFC's application framework is the document/view architecture, which defines a

program structure that relies on document objects to hold an application's data and on view objects to

render views of that data. MFC provides the infrastructure for documents and views in the classes

CDocument and CView. CWinApp , CFrameWnd, and other classes work in conjunction with CDocument

and CView to bind all the pieces together. It's a little early to discuss the details of the document/view

architecture, but you should at least be familiar with the term document/view because it inevitably comes

up in any discussion of MFC.

The reason documents and views are so important is that document/view applications derive the greatest

benefit from the application framework. You can write MFC programs that don't use documents and views

(and we'll do a lot of that in this book, especially in Chapters 1 through 8), but to get the most out of the

framework and take advantage of some of MFC's most advanced features, you must use the

document/view architecture. That's not as restricting as it sounds, because almost any program that relies

on documents of some type can be cast in the document/view mold. Don't let the term document mislead

you into thinking that the document/view architecture is useful only for writing word processors and

spreadsheet programs. A document is simply an abstract representation of a program's data. A document

could just as easily be a byte array that stores board positions in a computerized game of chess as it could

be a spreadsheet.

What kinds of support does MFC provide to document/view applications? Among other things, the

document/view architecture vastly simplifies printing and print previewing, the mechanics of saving

documents to disk and reading them back again, and converting applications into Active document servers

whose documents can be opened in Microsoft Internet Explorer. You'll learn all about the document/view

architecture in Part II of this book, but only after you've done some programming without documents and

views so that you can get to know MFC without having too much heaped on your plate at once.

The MFC Class Hierarchy

MFC provides a variety of classes designed to serve a wide range of needs. You'll find a handy diagram of

the MFC 6.0 class hierarchy inside the front cover of this book.

The majority of MFC classes are derived, either directly or indirectly, from CObject. CObject provides

three important features to classes that inherit from it:

Serialization support

Run-time class information support

Diagnostic and debugging support

Serialization is the process of streaming an object's persistent data to or from a storage medium such as a

disk file. By using CObject as a base class, you can write serializable classes whose instances are easily

saved and re-created. Run-time class information (RTCI) lets you retrieve an object's class name and

other information about the object at run time. RTCI is implemented apart from the run-time type

information (RTTI) mechanism in C++ because it predated RTTI by a number of years. Diagnostic and

debugging support built into CObject let you perform validity checks on instances of CObject-derived

classes and dump state information to a debugging window.

CObject provides other benefits to its derived classes as well. For example, it overloads the new and

delete operators to provide protection against memory leaks. If you create an object from a CObject-

derived class and fail to delete it before the application terminates, MFC will warn you by writing a

message to the debug output window. The overarching importance of this most basic of MFC classes will

become increasingly clear as you grow more familiar with MFC.

AFX Functions

Not all of the functions that MFC offers are members of classes. MFC provides an API of sorts all its own in

the form of global functions whose names begin with Afx. Class member functions can be called only in the

context of the objects to which they belong, but AFX functions are available anytime and anywhere.

The following table lists some of the more commonly used AFX functions. AfxBeginThread simplifies the

process of creating threads of execution. AfxMessageBox is the global equivalent of the Windows

MessageBox function and, unlike CWnd::MessageBox, can be called just as easily from a document class

as from a window class. AfxGetApp and AfxGetMainWnd return pointers to the application object and the

application's main window and are useful when you want to access a function or data member of those

objects but don't have a pointer readily available. AfxGetInstanceHandle is handy when you need an

instance handle to pass to a Windows API function. (Even MFC programs call API functions every now and

then!)

Commonly Used AFX Functions

Function Name Description

AfxAbort Unconditionally terminates an application; usually called when an

unrecoverable error occurs

AfxBeginThread Creates a new thread and begins executing it

AfxEndThread Terminates the thread that is currently executing

AfxMessageBox Displays a Windows message box

AfxGetApp Returns a pointer to the application object

AfxGetAppName Returns the name of the application

AfxGetMainWnd Returns a pointer to the application's main window

AfxGetInstanceHandle Returns a handle identifying the current application instance

AfxRegisterWndClass Registers a custom WNDCLASS for an MFC application

[Previous] [Next]

Your First MFC Application

It's time to build your first MFC application. And what better place to start than with one that displays

"Hello, MFC" in a window? Based on the classic "Hello, world" program immortalized in Brian Kernighan

and Dennis Ritchie's The C Programming Language (1988, Prentice-Hall), this very minimal program,

which I'll call Hello, demonstrates the fundamental principles involved in using MFC to write a Windows

application. Among other things, you'll get a close-up look at MFC's CWinApp and CFrameWnd classes and

see firsthand how classes are derived from them and plugged into the application. You'll also learn about

the all-important CPaintDC class, which serves as the conduit through which text and graphics are drawn

in a window in response to WM_PAINT messages. Finally, you'll be introduced to message mapping, the

mechanism MFC uses to correlate the messages your application receives with the member functions you

provide to handle those messages.

Figure 1-3 lists the source code for Hello. Hello.h contains the declarations for two derived classes.

Hello.cpp contains the implementations of those classes. Among C++ programmers, it's traditional to put

class definitions in .h files and source code in .cpp files. We'll honor that tradition here and throughout the

rest of this book. For large applications containing tens or perhaps hundreds of classes, it's also beneficial

to put class declarations and implementations in separate source code files. That's overkill for the

programs in the first few chapters of this book, but later on, when we begin working with documents and

views, we'll give each class its own .h and .cpp files. On the CD in the back of the book, in the folder

named Chap01, you'll find a folder with copies of Hello.h and Hello.cpp as well as a folder containing a

copy of the compiled executable (Hello.exe).

Figure 1-3. The Hello application.

Hello.h

class CMyApp : public CWinApp

{

public:

virtual BOOL InitInstance ();

};

class CMainWindow : public CFrameWnd

{

public:

CMainWindow ();

protected:

afx_msg void OnPaint ();

DECLARE_MESSAGE_MAP ()

};

Hello.cpp

#include <afxwin.h>

#include "Hello.h"

CMyApp myApp;

/////////////////////////////////////////////////////////////////////////

// CMyApp member functions

BOOL CMyApp::InitInstance ()

{

m_pMainWnd = new CMainWindow;

m_pMainWnd->ShowWindow (m_nCmdShow);

m_pMainWnd->UpdateWindow ();

return TRUE;

}

/////////////////////////////////////////////////////////////////////////

// CMainWindow message map and member functions

CMyApp declares no data members and overrides just one function inherited from CWinApp. InitInstance is

called early in the application's lifetime, right after the application starts running but before the window is

created. In fact, unless InitInstance creates a window, the application doesn't have a window. That's why

even a minimal MFC application must derive a class from CWinApp and override CWinApp::InitInstance.

The InitInstance Function

CWinApp::InitInstance is a virtual function whose default implementation contains just one statement:

return TRUE;

The purpose of InitInstance is to provide the application with the opportunity to initialize itself. The value

returned by InitInstance determines what the framework does next. Returning FALSE from InitInstance

shuts down the application. If initialization goes as planned, InitInstance should return TRUE in order to

allow the program to proceed. InitInstance is the perfect place to perform initializations that need to be

done each time the program starts. At the very least, this means creating the window that will represent

the application on the screen.

CMyApp's implementation of InitInstance, which appears in Hello.cpp, creates the Hello window by

instantiating Hello's CMainWindow class. The statement

m_pMainWnd = new CMainWindow;

constructs a CMainWindow object and copies its address to the application object's m_pMainWnd data

member. After the window is created, InitInstance displays it—remember, a window is not initially visible

unless it is created with a WS_VISIBLE attribute—by calling ShowWindow and UpdateWindow through the

CMainWindow pointer:

m_pMainWnd->ShowWindow (m_nCmdShow);

m_pMainWnd->UpdateWindow ();

ShowWindow and UpdateWindow are CWnd member functions common to all window objects, including

objects of the CFrameWnd class from which CMainWindow is derived. These functions are little more than

wrappers around the API functions of the same name. To call a regular Windows API function from an MFC

program, make it a practice to preface the function name with the global scope resolution operator ::, as

::UpdateWindow (hwnd);

This notation will ensure that the API function is called even if the object that makes the call has a member

function with the same name. In the remainder of this book, Windows API functions will be prefaced with

:: to distinguish them from MFC member functions.

ShowWindow accepts just one parameter: an integer that specifies whether the window should initially be

shown minimized, maximized, or neither minimized nor maximized. In accordance with Windows

programming protocol, Hello passes ShowWindow the value stored in the application object's

m_nCmdShow variable, which holds the nCmdShow parameter passed to WinMain. The m_nCmdShow

value is usually SW_SHOWNORMAL, indicating that the window should be displayed in its normal

unmaximized and unminimized state. However, depending on how the user starts an application, Windows

will occasionally slip in a value such as SW_SHOWMAXIMIZED or SW_SHOWMINIMIZED. Unless there is a

specific reason for it to do otherwise, InitInstance should always pass the m_nCmdShow variable instead

of a hardcoded SW_ value to ShowWindow.

UpdateWindow completes the job that ShowWindow started by forcing an immediate repaint. Its work

done, InitInstance returns TRUE to allow the application to proceed.

Other CWinApp Overridables

InitInstance is just one of several virtual CWinApp member functions you can override to customize the

behavior of the application object. Look up the CWinApp overridables in your MFC documentation and

you'll see a list of more than a dozen others with names such as WinHelp and ProcessWndProcException.

Many of these functions are seldom overridden, but they're handy to have around nonetheless. For

example, you can use ExitInstance to clean up when an application terminates. If you use InitInstance to

allocate memory or other resources, ExitInstance is the perfect place to free those resources. The default

剩余863页未读，继续阅读

kgdynisspam

粉丝: 2
资源: 4

MFC与Windows程序设计：第二版英文版精要指南

MFC Windows程序设计英文版

MFC Windows程序设计(第五版) 英文版 书籍和代码

中英文资料 MFC Windows程序设计（第二版）(Programming.Windows.with.MFC,.2nd.Edition).rar

MFC.Windows程序设计.第二版(英文版)

MFC.Windows程序设计.第二版（英文版）.pdf

MFC.Windows程序设计.第二版源码

MFC.Windows程序设计.第二版（英文版）.示例代码

[MFC.Windows程序设计(第2版)].(Programming.Windows.with.MFC,.2nd.Edition).Jeff.Prosise

MFC.Windows程序设计（第二版）（示例源码、电子书、安装包等全部）

MFC.Windows程序设计(第2版)修订版.iso

最新资源

MFC Windows程序设计(第五版) 英文版书籍和代码