MFC Programming Notes 1

总的来说，MFC封装了Win32 API、OLE API、ODBC API等底层函数的功能，比鞥提供更高一层的接口，简化Windows编程，同时，MFC支持对底层API的直接调用。下面是Microsoft MSDN 上一段对MFC要实现的目标的描述（http://msdn.microsoft.com/en-us/library/zscyw75e%28v=VS.100%29.aspx）：

The Microsoft Foundation Class Library is an object-oriented interface to Windows that meets the following design goals:

• Significant reduction in the effort to write an application for Windows.

• Execution speed comparable to that of the C-language API.

• Minimum code size overhead.

• Ability to call any Windows C function directly.

• Easier conversion of existing C applications to C++.

• Ability to leverage from the existing base of C-language Windows programming experience.

• Easier use of the Windows API with C++ than with C.

• Easier to use yet powerful abstractions of complicated features such as ActiveX controls, database support, printing, toolbars, and status bars.

• True Windows API for C++ that effectively uses C++ language features.

从自己的感觉来说，除了MFC的执行效率不尽人意以外，其他目标都得到了很好的实现。

MFC的核心是很多按照c++形式对windows api进行的封装(The core of the Microsoft Foundation Class (MFC) Library is an encapsulation of a large portion of the Windows API in C++ form.)

Message Map Macros(MFC)

to support message map,MFC supplies the following macros:

Message-Map Declaration and Demarcation Macros(消息映射声明和界定宏)

DECLARE_MESSAGE_MAP	declare that a message map will be used in a class to map messages to function(must be use in the class declartion)
BEGIN_MESSAGE_MAP	begins thw definition of a message map(must be use in the class inplementation)
END_MESSAGE_MAP	ends the definition of a messafe map (must be use in the class inplement)

 

Message Mapping Macros(消息映射宏)

ON_COMMAND	indicates which function will handle a specified command message
ON_CONTRL	indicates which function will handle a specified contrl-notification message
ON_MESSAGE	indicates which function will handle a uesr_defined  message
ON_OLECMD	indicates which function will handle a menu command from a DocObject or its container
ON_REGISTERED_MESSAGE	indicates which function will handle a registered user_defined message
ON_REGISTERED_THREAD_MESSAGE	indicates which function will handle a registered user_defined message when you have a CWinThread class
ON_THREAD_MESSAGE	indicates which function will handle a user_defined message when you have a CWinThread class
ON_UPDATE_COMMAND_UI	indicates which fuanction will handle a specified user_defiend update command message

 

Message Map Range Macros(消息映射边界宏)

ON_COMMAND_RANGE	indicates which function will handle the range of command IDs specified in the first two parameters to the macro
ON_UPDATE_COMMAND_UI_RANGE	indicates which update handler will handle the range of command IDs specified in the first two parameters to the macro
ON_CONTROL_RANGE	indicates which function will handle notification from yhe range of control IDs specified in the second and third parameter to the marco.the first parameter is a control-notification message ,such as BN_CLICKED

 

1、为应用程序添加重启管理器支持（restart manager support）功能

重启管理器（简称RM）是visual studio专门为Vista系统增加的特性，它支持当你的应用程序意外关闭的时候自动重新启动。重启管理器执行的操作依赖于你应用程序的类型。如果，应用程序是一个文档编辑器的话，RM就会自动保存你的修改，然后重启后自动打开当前编辑的文档。如果不是文档编辑类的，就不会保存相应的修改。

默认情况下，使用项目向导建立的MFC程序都会支持该功能，如果你不需要使用该功能的话，你可以删除该功能，也可以重载以实现自己的操作。

m_dwRestartManagerSupportFlags = AFX_RESTART_MANAGER_SUPPORT_ALL_ASPECTS;

 

2、#define ABC(X)

这条宏定义，没有给出实现是为了定义一个空宏，意图是为了以后扩展使用或者为了兼容以前版本。

#define后面的定义可以跟多条语句，但是必须要在一行里面，可以用’/’来声明为一行。

如：

#define Error(n)  n++;n+=5;
//
//#define  Error(n)   n++;/
//                             n+=5;

//#define Error(n)  n++;

//                           n+=5;      错误不在一行上面
int main()
{
    int n=9;
    Error(n);
    cout< <
    return 0;
}

在MFC中较复杂的例子就是：

#define DECLARE_DYNCREATE(class_name)  /

              DECLARE_DYNAMIC(class_name) /

           static CObject* PASCAL CreateObject();

简单的从#define替换的功能上来说就是，在出现DECLARE_DYNCREATE(class_name)的地方，就用

DECLARE_DYNAMIC(class_name)

static CObject* PASCAL CreateObject();

来替换。全部展开的话就是：

#define DECLARE_DYNAMIC(class_name) /
protected: /
    static CRuntimeClass* PASCAL _GetBaseClass(); /
public: /
    static const CRuntimeClass class##class_name; /
    static CRuntimeClass* PASCAL GetThisClass(); /
    virtual CRuntimeClass* GetRuntimeClass() const; /

static CObject* PASCAL CreateObject();

在类中使用了DECLARE_DYNAMIC后，还要在.cpp的文件中使用IMPLEMENT_DYNAMIC宏，该宏的作用就是初始化class##class_name对象和定义GetRuntimeClass函数。

3、以传统的C/SDK编写windows程序，显而易见的好处就是可以清楚的了解整个程序的来龙去脉和消息流向；MFC提供了更高级的结构支持和封装组装，结构支持是指文档/视图结构，封装组装是指用户界面UI。具有UI性质的主要有工具栏、状态栏、打印和预览等。

4、windows 消息可以分成3种：

1、窗口消息 windows messages

大部分都是以WM_开头的消息，除了WM_COMMAND不属于窗口消息以外。windows message是由窗口和视（views）来处理的。并且这些消息里包含了怎样处理该消息的参数。

2、控件通知消息 control notifications

控件通知消息主要是来自控件或子窗口向父窗口传送的WM_COMMAND消息。控件消息是由框架（framework）来处理的，对控件消息的路由过程和windows message类似， 除了一个例外：BN_CLICKED(This message is sent when the user taps the pen on the touch screen. The parent window of the button receives this message through the WM_COMMAND message.)。BN_CLICKED是由父窗口来处理的。

3、命令消息 command messages

命令消息包括来自用户接口对象（use interface objects：如菜单，工具栏按钮，快捷键）的WM_COMMAND通知消息。framework对于这些信息的传递采用与其他不同的放式，它们可以被多种对象处理，详情请见另一篇文章：Command Targets

（也可以查看http://msdn.microsoft.com/en-us/library/dbhy1w2d.aspx文档）。

窗口消息和控件通知消息是由一些类所定义的窗口来处理的，这些类可以是CWnd类的子类包括：CFrameWnd，CMDIFrameWnd，CMDIChildWnd，CView，CDialog.另外还用你自己定义的派生自CWnd的窗口。这些类里面都封装了一个HWND，来指向窗口。

命令消息可以被很多的对象处理：文件（document）、文件模板（document template）还有应用程序本身（除了该应用还程序自己的窗口和视（view））。

4、MFC概况

MFC可以分成以下几类：

Windows API 类  ：用来封装WindowsAPI

Application Framework 类：即应用程序体系结构类，组成应用程序的骨干，包括文档/视、消息映射、消息传递、动态创建、文件读写等，使MFC跻身Application Framework的关键技术是文档/视。

High Level Abstractions类：这些高度抽象的类都属于视觉性质的UI对象类，例如工具栏（CToolBar）、状态类（CStateBar）和对话框（CDialogBar）。加强型的View也属于此类。

General Purpose类：提供字符串类、数据处理类（如数组和链表）、异常情况处理类、文件类等。

Operation System Extensions类：操作系统扩展类，包括OLE、ODBC、DAO、MAPI、Winsock和ISAPI等。

5、Application可用的四种字体：

Raster（点阵）, Vector（向量）, TrueType, and OpenType Fonts

Applications can use four different kinds of font technologies to display and print text:

• Raster
• Vector
• TrueType
• Microsoft OpenType

The differences between these fonts reflect the way that the glyph（字形） for each character or symbol is stored in the respective font-resource file:

• In raster fonts, a glyph is a bitmap that the system uses to draw a single character or symbol in the font.
• In vector fonts, a glyph is a collection of line endpoints that define the line segments that the system uses to draw a character or symbol in the font.
• In TrueType and OpenType fonts, a glyph is a collection of line and curve commands as well as a collection of hints.

The system uses the line and curve commands to define the outline of the bitmap for a character or symbol in the TrueType or Microsoft OpenType font. The system uses the hints to adjust the length of the lines and shapes of the curves used to draw the character or symbol. These hints and the respective adjustments are based on the amount of scaling used to reduce or increase the size of the bitmap. An OpenType font is equivalent to a TrueType font except that an OpenType font allows PostScript glyph definitions in addition to TrueType glyph definitions.

Because the bitmaps for each glyph in a raster font are designed for a specific resolution of device, raster fonts are generally considered to be device dependent. Vector fonts, on the other hand, are not device dependent, because each glyph is stored as a collection of scalable lines. However, vector fonts are generally drawn more slowly than raster or TrueType and OpenType fonts. TrueType and OpenType fonts provide both relatively fast drawing speed and true device independence. By using the hints associated with a glyph, a developer can scale the characters from a TrueType or OpenType font up or down and still maintain their original shape.

As previously mentioned, the glyphs for a font are stored in a font-resource file. A font-resource file is actually a DLL that contains only datathere is no code. For raster and vector fonts, this data is divided into two parts: a header describing the font's metrics and the glyph data. A font-resource file for a raster or vector font is identified by the .fon file name extension. For TrueType and OpenType fonts, there are two files for each font: the first file contains a relatively short header and the second contains the actual font data. The first file is identified by an .fot extension and the second is identified by a .ttf extension.

******************************************************************************************************************************************************

Windows GDI

Character Sets Used by Fonts

All fonts use a character set. A character set contains punctuation marks, numerals, uppercase and lowercase letters, and all other printable characters. Each element of a character set is identified by a number.

Most character sets in use are supersets of the U.S. ASCII character set, which defines characters for the 96 numeric values from 32 through 127. There are five major groups of character sets:

• Windows
• Unicode
• OEM (original equipment manufacturer)
• Symbol
• Vendor-specific

Windows Character Set

The Windows character set is the most commonly used character set. It is essentially equivalent to the ANSI character set. The blank character is the first character in the Windows character set. It has a hexadecimal value of 0x20 (decimal 32). The last character in the Windows character set has a hexadecimal value of 0xFF (decimal 255).

Many fonts specify a default character. Whenever a request is made for a character that is not in the font, the system provides this default character. Many fonts using the Windows character set specify the period (.) as the default character. TrueType and OpenType fonts typically use an open box as the default character.

Fonts use a break character called a quad to separate words and justify text. Most fonts using the Windows character set specify that the blank character will serve as the break character.

Unicode Character Set

The Windows character set uses 8 bits to represent each character; therefore, the maximum number of characters that can be expressed using 8 bits is 256 (2^8). This is usually sufficient for Western languages, including the diacritical marks used in French, German, Spanish, and other languages. However, Eastern languages employ thousands of separate characters, which cannot be encoded by using a single-byte coding scheme. With the proliferation of computer commerce, double-byte coding schemes were developed so that characters could be represented in 8-bit, 16-bit, 24-bit, or 32-bit sequences. This requires complicated passing algorithms; even so, using different code sets could yield entirely different results on two different computers.

To address the problem of multiple coding schemes, the Unicode standard for data representation was developed. A 16-bit character coding scheme, Unicode can represent 65,536 (2^16) characters, which is enough to include all languages in computer commerce today, as well as punctuation marks, mathematical symbols, and room for expansion. Unicode establishes a unique code for every character to ensure that character translation is always accurate.

OEM Character Set

The OEM character set is typically used in full-screen MS-DOS sessions for screen display. Characters 32 through 127 are usually the same in the OEM, U.S. ASCII, and Windows character sets. The other characters in the OEM character set (0 through 31 and 128 through 255) correspond to the characters that can be displayed in a full-screen MS-DOS session. These characters are generally different from the Windows characters.

Symbol Character Set

The Symbol character set contains special characters typically used to represent mathematical and scientific formulas.

Vendor-Specific Character Sets

Many printers and other output devices provide fonts based on character sets that differ from the Windows and OEM setsfor example, the Extended Binary Coded Decimal Interchange Code (EBCDIC) character set. To use one of these character sets, the printer driver translates from the Windows character set to the vendor-specific character set.

---