深入浅出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,如需转载请自行联系原作者



相关文章
|
8月前
|
SQL NoSQL 前端开发
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
|
5月前
|
JSON 前端开发 API
Django 后端架构开发:通用表单视图、组件对接、验证机制和组件开发
Django 后端架构开发:通用表单视图、组件对接、验证机制和组件开发
75 2
|
5月前
|
JSON 数据处理 API
Django后端架构开发:视图与模板的正确使用
Django后端架构开发:视图与模板的正确使用
52 1
|
8月前
|
存储 设计模式 前端开发
请解释 Web 应用程序的 MVC(模型-视图-控制器)架构。
【2月更文挑战第26天】【2月更文挑战第89篇】请解释 Web 应用程序的 MVC(模型-视图-控制器)架构。
64 0
|
8月前
MFC应用程序对话框架构
MFC应用程序对话框架构
42 0
|
8月前
MFC单文档视图架构
MFC单文档视图架构
66 0
|
29天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
2月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
46 3
|
2月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
28天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
154 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型

热门文章

最新文章