深入浅出MFC(2)

消息映射与命令传递(Message Mapping and Command Routing)
    各种消息之中，来自菜单或工具栏者，都以WM_COMMAND表示，所以这一类消息我们又称之为命令消息， 其qParam纪录着此消息来自哪一个菜单项目。
   各种命令消息，还有一种消息也比较特殊，出现在对话框函数中，是控件传递给父窗口的消息。虽然他们也以WM_COMMAND为外衣，但特别归类为"notification"消息。
   消息会循着Application Framework规定的路线，游走与各个对象之间，直到找到它的归宿(消息处理函数），找不到的话，Framework最终就把它交给::DefWindowProc函数去处理。
消息分类
   Windows的消息都是以WM_XXX为名，WM的意思是"Windows Message".消息可以使来自硬件的"输入消息"，例如WM_LBUTTONDOWN，也可以是来自USER模块的"窗口管理消息"，例如"WM_CREATE"。这些消息在MFC程序中都是隐晦的(意思是不像在SDK中那么明显)，我们不必在MFC程序中撰写switch case指令，不必一一识别并处理系统送过来的消息；所有消息都将依循Frmaework指定的路线，并参照路线是否有拦路虎(你的消息映射表格)而流动。WM_PAINT一定流往你的OnPaint函数去，WM_SIZE一定是流往你的OnSize函数里。
   所有消息在MFC程序中都是暗潮汹涌，但是表面无波。
   MFC把消息分为三大类：
   命令消息(WM_COMMAND)：命令消息意味着"使用者命令程序作某些操作".
凡由UI对象产生的消息都是这种命令消息,可能来自菜单或者加速键或者工具栏按钮,并且都以WM_COMMAND呈现.如何分辨来自各处的命令消息?SDK程序主要靠消息的wParam识别的，MFC程序则主要靠菜单项的识别码识别的---两者其实是相同的。
   什么样的类有资格接受命令消息？凡派生自CCmdTarget的类，皆有资格。从command target的字面的意义可知，这是命令消息的目的地。也就是说，凡派生自CCmdTarget者，它的骨子里就有一种派生机制，把整张MFC类层次图摊开来看，几乎建立应用程序的最重要的几个类都派生自CCmdTarget，剩下的就不能接受消息了，是象CFile，CArchive，CPoint，CDao（数据库)类。
   标准消息:除WM_COMMAND之外，任何以WM_开头的都算是这一类，任何派生自CWnd之类，均可以接受此消息。
   Control Notification：这种消息由控件产生，为的是向其父窗口（通常是对话框）通知某种情况。例如当你在ListBox上选择其中一个项目，ListBox就会产生LBN_SELECHANGE传送给父窗口，这类消息也是以WM_COMMAND形式出现的。

维护UI对象状态(UPDATE_COMMAND_UI)
   一个菜单拉下来,使用者可以从命令项的状态(打勾或者没有打勾,灰色或者正常)得到一些状态提示.
   所有UI对象状态的维护可以依赖所谓的(UPDATE_COMMAND_UI)消息.
   传统SDK程序中要改变菜单命令项状态,可以调用EnableMenuItem或者CheckMenuItem，但这使得程序杂乱无章，因为你没有一个固定的位置和固定的原则处理命令项的状态。MFC提供一种直觉并且仍旧依赖消息观念的方式，解决这个问题，这就是UPDATE_COMMAND_UI消息。其设计理念是，每当菜单被下拉尚未显示之前，其命令项（以及对应工具栏按钮）都会收到UPDATE_COMMAND_UI消息，这个消息和WM_COMMEND有一样的传递路线，我们只要在适当的类中放置其处理函数，并在函数中作某些判断，便可以解决如何显示命令项。
    MFC和对话框
    ClassWizard可以帮助我们新增类，并增加该类的成员变量，以及设定对话框的DDX/DDV。（ＤＤＸ和ＤＤＶ）先做DDX,在做DDV，这是游戏规则。如果纯粹借助ClassWizard，就不必在意此事，如果要自己动手完成，就要遵循规则。
    所谓ＤＤＸ是指让我们把对话框类中的成员变量与对话框中的控件产生关联，于是当对话框结束时，空间的内容会自动传输到这些成员变量上。
    所谓ＤＤＶ是指允许我们设定对话框控件的内容的类型以及数据（数值）范围。