深入浅出MFC“文档/视图”架构(6)--相互关系及消息流动

简介:


深入浅出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.16.2分别给出了一个多文档/视图框架MFC程序的组成以及其中所包含类的层次关系。
6.1 多文档/视图框架MFC程序的组成
6.2 文档/视图框架程序类的层次关系
关于文档和视图的关系,我们可进一步细分为三类:
1)文档对应多个相同的视图对象,每个视图对象在一个单独的 MDI 文档框架窗口中;
2)文档对应多个相同类的视图对象,但这些视图对象在同一文档框架窗口中(通过“拆分窗口”即将单个文档窗口的视图空间拆分成多个单独的文档视图实现);
3)文档对应多个不同类的视图对象,这些视图对象仅在一个单独的 MDI 文档框架窗口中。在此模型中,由不同的类构造成的多个视图共享单个框架窗口,每个视图可提供查看同一文档的不同方式。例如,一个视图以字处理模式显示文档,而另一个视图则以“文档结构图”模式显示文档。
6.3显示了对应三种文档与视图关系应用程序的界面特点。
6.3文档/视图的三种关系
2.  消息流动机制
在基于“文档/视图”架构的MFC程序中,用户消息(鼠标、键盘输入等)会先发往视图,如果视图未处理则会发往框架窗口。所以,一般来说,消息映射宜定义在视图中。另外,如果一个应用同时拥有多个视图而当前活动视图没有对消息进行处理则消息也会发往框架窗口。
下面我们来看实例,我们利用Visual C++向导创建一个单文档/视图架构的MFC程序,在其中增加一个菜单项为“自定义”(IDIDM_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::OnCmdMsgCView::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,如需转载请自行联系原作者



相关文章
|
2月前
|
SQL NoSQL 前端开发
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
|
2月前
|
存储 设计模式 前端开发
请解释 Web 应用程序的 MVC(模型-视图-控制器)架构。
【2月更文挑战第26天】【2月更文挑战第89篇】请解释 Web 应用程序的 MVC(模型-视图-控制器)架构。
|
2月前
MFC应用程序对话框架构
MFC应用程序对话框架构
22 0
|
2月前
MFC单文档视图架构
MFC单文档视图架构
29 0
|
2月前
|
JSON 前端开发 Java
SpringMVC的架构有什么优势?——视图与模型(二)
SpringMVC的架构有什么优势?——视图与模型(二)
|
2月前
|
开发框架 架构师 Java
Java程序员不掌握SpringBoot怎么进大厂,阿里架构师推荐实战文档
Spring Boot作为Java编程语言的一个全新开发框架,在国内外才刚刚兴起时,还未得到普及使用。
|
4天前
|
缓存 监控 负载均衡
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关如同一座灯塔,指引着服务间的通信。本文将深入探讨API网关的设计哲学、关键功能以及在实际应用中的考量因素。通过对比分析,我们将揭示API网关如何在提高系统可维护性、增强安全性和优化性能方面发挥其不可或缺的作用。此外,文章还将提供实践指南,帮助读者在构建或改进微服务架构时,做出明智的API网关选择和部署决策。
|
4天前
|
Kubernetes 持续交付 开发者
探索后端技术的未来:微服务架构与容器化部署的融合
在数字化时代的浪潮中,后端技术正经历着前所未有的变革。本文将深入探讨微服务架构和容器化部署如何共同推动后端技术的发展,提升应用的性能、可扩展性和可靠性。通过分析现代软件开发的需求,我们将揭示这两种技术如何互补,以及它们在未来后端开发中的潜力和挑战。
|
1天前
|
负载均衡 监控 安全
微服务架构下的API网关实践
在微服务架构的实践中,API网关作为系统入口的关键组件,承载着请求路由、负载均衡、认证授权等核心功能。本文将深入探讨API网关的设计与实现,通过具体案例分析其在微服务架构中的应用场景和挑战,并分享实践经验与优化策略,旨在为开发者提供一份实用的API网关部署指南。
|
3天前
|
存储 负载均衡 数据库
探索微服务架构中的服务发现机制
【7月更文挑战第24天】在微服务架构的复杂网络中,服务发现是确保通信流畅与系统弹性的关键组件。本文将深入探讨服务发现的工作原理、面临的挑战以及解决方案,同时比较不同服务发现工具的性能特点,旨在为开发者提供实现高效服务发现的实战指南。