深入浅出MFC“文档/视图”架构（6）
――模板、文档、视图、框架的关系及消息流动机制
作者：宋宝华 e-mail:21cnbao@21cn.com
1.
模板、文档、视图、框架的关系
连载1~5我们各个击破地讲解了文档、文档模板、视图和框架类，连载1已经强调这些类有着亲密的内部联系，总结1~5我们可以概括其联系为：
（1）文档保留该文档的视图列表和指向创建该文档的文档模板的指针；文档至少有一个相关联的视图，而视图只能与一个文档相关联。
（2）视图保留指向其文档的指针，并被包含在其父框架窗口中；
（3）文档框架窗口（即包含视图的MDI子窗口）保留指向其当前活动视图的指针；
（4）文档模板保留其已打开文档的列表，维护框架窗口、文档及视图的映射；
（5）应用程序保留其文档模板的列表。
我们可以通过一组函数让这些类之间相互可访问，表6-1给出这些函数。
表6-1 文档、文档模板、视图和框架类的互相访问
从该对象
如何访问其他对象
全局函数
调用全局函数AfxGetApp可以得到CWinApp应用类指针
应用
AfxGetApp()->m_pMainWnd为框架窗口指针；
用CWinApp::GetFirstDocTemplatePostion、CWinApp::GetNextDocTemplate来遍历所有文档模板
文档
调用CDocument::GetFirstViewPosition，CDocument::GetNextView来遍历所有和文档关联的视图；
调用CDocument:: GetDocTemplate 获取文档模板指针
文档模板
调用CDocTemplate::GetFirstDocPosition、CDocTemplate::GetNextDoc来遍历所有对应文档
视图
调用CView::GetDocument 得到对应的文档指针；
调用CView::GetParentFrame 获取框架窗口
文档框架窗口
调用CFrameWnd::GetActiveView 获取当前得到当前活动视图指针；
调用CFrameWnd::GetActiveDocument 获取附加到当前视图的文档指针
MDI 框架窗口
调用CMDIFrameWnd::MDIGetActive 获取当前活动的MDI子窗口（CMDIChildWnd）
我们列举一个例子，综合应用上表中的函数，写一段代码，它完成遍历文档模板、文档和视图的功能：
CMyApp *pMyApp = (CMyApp*)AfxGetApp(); //得到应用程序指针
POSITION p = pMyApp->GetFirstDocTemplatePosition();//得到第1个文档模板
while (p != NULL) //遍历文档模板
{
CDocTemplate *pDocTemplate = pMyApp->GetNextDocTemplate(p);
POSITION p1 = pDocTemplate->GetFirstDocPosition();//得到文档模板对应的第1个文档
while (p1 != NULL) //遍历文档模板对应的文档
{
CDocument *pDocument = pDocTemplate->GetNextDoc(p1);
POSITION p2 = pDocument->GetFirstViewPosition(); //得到文档对应的第1个视图
while (p2 != NULL) //遍历文档对应的视图
{
CView *pView = pDocument->GetNextView(p2);
}
}
}
由此可见，下面的管理关系和实现途径都是完全类似的：
（1）应用程序之于文档模板；
（2）文档模板之于文档；
（3）文档之于视图。
图6.1、6.2分别给出了一个多文档/视图框架MFC程序的组成以及其中所包含类的层次关系。
图6.1 多文档/视图框架MFC程序的组成
图6.2 文档/视图框架程序类的层次关系
关于文档和视图的关系，我们可进一步细分为三类：
（1）文档对应多个相同的视图对象，每个视图对象在一个单独的 MDI 文档框架窗口中；
（2）文档对应多个相同类的视图对象，但这些视图对象在同一文档框架窗口中（通过“拆分窗口”即将单个文档窗口的视图空间拆分成多个单独的文档视图实现）；
（3）文档对应多个不同类的视图对象，这些视图对象仅在一个单独的 MDI 文档框架窗口中。在此模型中，由不同的类构造成的多个视图共享单个框架窗口，每个视图可提供查看同一文档的不同方式。例如，一个视图以字处理模式显示文档，而另一个视图则以“文档结构图”模式显示文档。
图6.3显示了对应三种文档与视图关系应用程序的界面特点。
图6.3文档/视图的三种关系
2.
消息流动机制
在基于“文档/视图”架构的MFC程序中，用户消息（鼠标、键盘输入等）会先发往视图，如果视图未处理则会发往框架窗口。所以，一般来说，消息映射宜定义在视图中。另外，如果一个应用同时拥有多个视图而当前活动视图没有对消息进行处理则消息也会发往框架窗口。
下面我们来看实例，我们利用Visual C++向导创建一个单文档/视图架构的MFC程序，在其中增加一个菜单项为“自定义”（ID为IDM_SELF，如图6.4）。
图6.4 含“自定义”菜单的单文档/视图架构MFC程序
我们分别在视图类和框架窗口类中为“自定义”菜单添加消息映射，代码如下：
//视图中的消息映射和处理函数
BEGIN_MESSAGE_MAP(CExampleView, CView)
//{{AFX_MSG_MAP(CExampleView)
ON_COMMAND(IDM_SELF, OnSelf)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
void CExampleView::OnSelf()
{
// TODO: Add your command handler code here
AfxMessageBox("消息在视图中处理");
}
//框架窗口中的消息映射和处理函数
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)
//{{AFX_MSG_MAP(CMainFrame)
ON_COMMAND(IDM_SELF, OnSelf)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
void CMainFrame::OnSelf()
{
// TODO: Add your command handler code here
AfxMessageBox("消息在框架窗口中处理");
}
这时候，我们单击“自定义”菜单，弹出对话框显示"消息在视图中处理"；如果我们删除框架窗口中的消息映射，再单击“自定义”菜单，弹出对话框也显示"消息在视图中处理"；但是，若我们将视图中的消息映射删除了，就会显示"消息在框架窗口中处理"！这验证了我们关于消息处理顺序论述的正确性。
欲深入理解消息流动过程，还需认真分析CFrameWnd::OnCmdMsg、CView::OnCmdMsg函数的源代码：
BOOL CFrameWnd::OnCmdMsg(UINT nID, int nCode, void* pExtra,
AFX_CMDHANDLERINFO* pHandlerInfo)
{
// pump through current view FIRST
CView* pView = GetActiveView();
if (pView != NULL && pView->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
return TRUE;
// then pump through frame
if (CWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
return TRUE;
// last but not least, pump through app
CWinApp* pApp = AfxGetApp();
if (pApp != NULL && pApp->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
return TRUE;
return FALSE;
}
BOOL CView::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
// first pump through pane
if (CWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
return TRUE;
// then pump through document
BOOL bHandled = FALSE;
if (m_pDocument != NULL)
{
// special state for saving view before routing to document
_AFX_THREAD_STATE* pThreadState = AfxGetThreadState();
CView* pOldRoutingView = pThreadState->m_pRoutingView;
pThreadState->m_pRoutingView = this;
bHandled = m_pDocument->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);
pThreadState->m_pRoutingView = pOldRoutingView;
}
return bHandled;
}
分析上述源代码可知，WM_COMMAND消息的实际流动顺序比前文叙述的“先视图，后框架窗口”要复杂得多，文档和应用程序都参与了消息的处理过程。如果我们再为文档和应用添加消息映射和处理函数：
//文档的消息映射和处理函数
BEGIN_MESSAGE_MAP(CExampleDoc, CDocument)
//{{AFX_MSG_MAP(CExampleDoc)
ON_COMMAND(IDM_SELF, OnSelf)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
void CExampleDoc::OnSelf()
{
// TODO: Add your command handler code here
AfxMessageBox("消息在文档中处理");
}
//应用的消息映射和处理函数
BEGIN_MESSAGE_MAP(CExampleApp, CWinApp)
//{{AFX_MSG_MAP(CExampleApp)
ON_COMMAND(IDM_SELF, OnSelf)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
void CExampleApp::OnSelf()
{
// TODO: Add your command handler code here
AfxMessageBox("消息在应用中处理");
}
屏蔽掉视图和框架窗口的消息映射，再单击“自定义”菜单，弹出对话框显示"消息在文档中处理"；再屏蔽掉文档中的消息映射，弹出对话框显示"消息在应用中处理"！由此可见，完整的WM_COMMAND消息的处理顺序是“视图――文档――框架窗口――应用”！
实际上，关于MFC的消息流动是一个很复杂的议题，陷于篇幅的原因，我们不可能对其进行更详尽的介绍，具体可以参看《深入浅出MFC》第2版第9章。
本文转自 21cnbao 51CTO博客，原文链接：http://blog.51cto.com/21cnbao/120300，如需转载请自行联系原作者
