本人对Windows系统、MFC谈不上有深入的了解,但对MFC本身包装API的机制很有兴趣,特别是读了候老师的《深入浅出 MFC》后,感觉到VISUAL C++的Application FrameWork十分精制[不敢用“完美”一词]。在以前,我对SDI结构处理消息有一定的认识,但对于模式对话框的消息机制不了解,读了《深入》一书 也没能得到解决,近日,通过在CSDN上网友的帮助,和查阅MSDN,自认为已经了解。一时兴起,写下这些文字,没有其它目的,只是希望让后来者少走弯 路,也希望和我一样喜欢“钻牛角尖”的人共同讨论、学习。如果你是牛人,那么你现在要慎重考虑有没有充足的时间读这些幼稚文字[何出此言?请大家看一下:http://www.csdn.net/expert/topic/13/13451.xml的相关评论]。本文中有些“理论”是我自己胡乱猜测,还请大家指正.[文中内容有些不可避免的会和《深入》一书某些内容重复]。
正文:
Windows程序和DOS程序的主要不同点之一是:Windows程序是以事件为驱动、消息机制为基础。如何理解?
举了例子,当你CLICK Windows “开始”BUTTON时,为什么就会弹出一个菜单呢?
当你单击鼠标左键时,操作系统中与MOUSE相关的驱动程序在第一时间内得到这个信号[LBUTTONDOWN],然后它通知操作系统―――“嗨,鼠标左键被单击了!”,操作系统得到这一信号后,马上要判断――用户单击鼠标左键,这是针对哪个窗口呢?如何判断?这很简单!当前状态中,具有焦点的窗口[或控件]就是了[这里当然是“开始”BUTTON了]。然后操作系统马上向这个窗口发送一条消息到这个窗口所在进程的消息队列,消息内容应是消息本身的代号、附加参数、窗口句柄…等等了。那么,只有操作系统才有资格发送消息至某一窗口的消息队列吗?不然,其它程序也有资格。你可以在你的程序中调用:SendMessage 、PostMessage。这样,被单击的窗口得到了一条由操作系统发送的包含CLICK的消息,操作系统已经暂时不再管窗口的任何事,因为它还要忙于处理其它事务。你的程序得到一条消息后如何做呢?Windows对于你在“开始”BUTTON上的单击事件做出如下反映:弹出一菜单。可是,得到消息到做出反映这一过程是如何实现的呢?这就是本文讨论的主要内容[当然只是针对MFC了]。
我首先简要谈一下SDI,然后会花更多文字描述模式对话框。
对于SDI窗口,你的应用程序类的InitInstance()大约如下:
BOOL CEx06aApp::InitInstance()
{ ……………
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CEx06aDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CEx06aView));
AddDocTemplate(pDocTemplate);
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
if (!ProcessShellCommand(cmdInfo))
return FALSE;
m_pMainWnd->ShowWindow(SW_SHOW);
m_pMainWnd->UpdateWindow();
return TRUE;
}
完成一些如动态生成相关文档、视,显示主框架窗口、处理参数行信息等工作。这些都是显示在你工程中的“明码”。我们现在把断点设置到return TRUE;一句,跟入MFC源码中,看看到底MFC内部做了什么。
程序进入SRC\WinMain.cpp,下一个大动作应是:
nReturnCode = pThread->Run();
各位看官注意了,重点来了。F11进入
int CWinApp::Run()
{
if (m_pMainWnd == NULL && AfxOleGetUserCtrl())
{
// Not launched /Embedding or /Automation, but has no main window!
TRACE0("Warning: m_pMainWnd is NULL in CWinApp::Run - quitting application.\n");
AfxPostQuitMessage(0);
}
return CWinThread::Run();
}
再次F11进入:
int CWinThread::Run()
{
ASSERT_VALID(this);
// for tracking the idle time state
BOOL bIdle = TRUE;
LONG lIdleCount = 0;
// acquire and dispatch messages until a WM_QUIT message is received.
for (;;)
{
// phase1: check to see if we can do idle work
while (bIdle &&
!::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE))
{
// call OnIdle while in bIdle state
if (!OnIdle(lIdleCount++))
bIdle = FALSE; // assume "no idle" state
}
// phase2: pump messages while available
do
{
// pump message, but quit on WM_QUIT
if (!PumpMessage())
return ExitInstance();
// reset "no idle" state after pumping "normal" message
if (IsIdleMessage(&m_msgCur))
{
bIdle = TRUE;
lIdleCount = 0;
}
} while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE));
}
ASSERT(FALSE); // not reachable
}
BOOL CWinThread::IsIdleMessage(MSG* pMsg)
{
// Return FALSE if the message just dispatched should _not_
// cause OnIdle to be run. Messages which do not usually
// affect the state of the user interface and happen very
// often are checked for.
// redundant WM_MOUSEMOVE and WM_NCMOUSEMOVE
if (pMsg->message == WM_MOUSEMOVE || pMsg->message == WM_NCMOUSEMOVE)
{
// mouse move at same position as last mouse move?
if (m_ptCursorLast == pMsg->pt && pMsg->message == m_nMsgLast)
return FALSE;
m_ptCursorLast = pMsg->pt; // remember for next time
m_nMsgLast = pMsg->message;
return TRUE;
}
// WM_PAINT and WM_SYSTIMER (caret blink)
return pMsg->message != WM_PAINT && pMsg->message != 0x0118;
}
这是SDI处理消息的中心机构,但请注意,它觉对不是核心!
分析一下,在无限循环FOR内部又出现一个WHILE循环
while (bIdle &&
!::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE))
{
// call OnIdle while in bIdle state
if (!OnIdle(lIdleCount++))
bIdle = FALSE; // assume "no idle" state
}
这段代码是当你程序进程的消息队列中没有消息时,会调用OnIdle做一些后备工作,
临 时对象在这里被删除。当然它是虚函数。其中的PeekMessage,是查看消息队列,如果有消息返回TRUE,如果没有消息返回FALSE,这里指定 PM_NOREMOVE,是指查看过后不移走消息队列中刚刚被查看到的消息,也就是说这里的PeekMessage只起到一个检测作用,显然返回 FALSE时[即没有消息],才会进入循环内部,执行OnIdle,当然了,你的OnIdle返回FLASE,会让程序不再执行OnIdle。你可能要问:
当bidle=0或消息队例中有消息时,程序又执行到哪了呢?
do
{
// pump message, but quit on WM_QUIT
if (!PumpMessage())
return ExitInstance();
// reset "no idle" state after pumping "normal" message
if (IsIdleMessage(&m_msgCur))
{
bIdle = TRUE;
lIdleCount = 0;
}
} while (::PeekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE));
看啊,又进入一个循环!
其中有个重要的函数,PumpMessage,内容如下:
BOOL CWinThread::PumpMessage()
{
ASSERT_VALID(this);
if (!::GetMessage(&m_msgCur, NULL, NULL, NULL))
{
#ifdef _DEBUG
if (afxTraceFlags & traceAppMsg)
TRACE0("CWinThread::PumpMessage - Received WM_QUIT.\n");
m_nDisablePumpCount++; // application must die
// Note: prevents calling message loop things in 'ExitInstance'
// will never be decremented
#endif
return FALSE;
}
#ifdef _DEBUG
if (m_nDisablePumpCount != 0)
{
TRACE0("Error: CWinThread::PumpMessage called when not permitted.\n");
ASSERT(FALSE);
}
#endif
#ifdef _DEBUG
if (afxTraceFlags & traceAppMsg)
_AfxTraceMsg(_T("PumpMessage"), &m_msgCur);
#endif
// process this message
if (m_msgCur.message != WM_KICKIDLE && !PreTranslateMessage(&m_msgCur))
{
::TranslateMessage(&m_msgCur);
::DispatchMessage(&m_msgCur);
}
return TRUE;
}
如你所想,这才是MFC消息处理的核心基地[也是我个人认为的]。
GetMessage 不同于PeekMessae,它是不得到消息不罢体,PeekMessage如果发现消息队列中没有消息会返回0,而GetMessage如果发现没有消 息,等,直到有了消息,而且,GetMessage不同于PeekMessage,它会将消息移走[当然,PeekMessage也可以做到这点]。我想 当你读了这个函数后,你应明白PreTranslateMessage函数的用法了吧[我比较喜欢在程序中充分利用这个函数]。
::TranslateMessage(&m_msgCur);
::DispatchMessage(&m_msgCur);
将消息发送到窗口的处理函数[它是由窗口类指定的],之后的动作一直到你的程序做出反映的过程,你可以在《深入》一书中得到完美的解释。我们还是通过reurn TRUE;回到CWinThread::Run()中的Do{}while;循环。然后还是对IDLE的处理,即便刚才你的ONIDLE返回了FALSE,在这里你看到,你的程序还是有机会执行它的。然后又是利用PeekMessage检测消息队列:
如果有消息[这个消息不被移动的原因是因为它要为PumpMessage内的GetMessage所利用。]再次进入PumpMessage[叫它“消息泵”吧]。
如果没有消息,退出DO循环,但它还在FOR内部,所以又执行第一个While循环。
这是CwinThread::Run的一个执行过程。
不用担心退不出for(;;)如果你的消息队列中有一条WM_QUIT,会使GetMessage返回0,然后PumpMessage返回0而RUN()内部:
if (!PumpMessage())
return ExitInstance();。
SDI就说到这,下面我来谈一下模式对话框。我分2种情况讨论:
一当你的工程以模式对话框为基础时[没父窗口,或为桌面]。
与SDI不同处在于,在应用程序类的InItInstance内部:
BOOL CComboBoxApp::InitInstance()
{
AfxEnableControlContainer();
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need.
#ifdef _AFXDLL
Enable3dControls(); // Call this when using MFC in a shared DLL
#else
Enable3dControlsStatic(); // Call this when linking to MFC statically
#endif
this->m_nCmdShow = SW_HIDE;
CComboBoxDlg dlg;
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
// TODO: Place code here to handle when the dialog is
// dismissed with OK
}
else if (nResponse == IDCANCEL)
{
// TODO: Place code here to handle when the dialog is
// dismissed with Cancel
}
// Since the dialog has been closed, return FALSE so that we exit the
// application, rather than start the application's message pump.
return FALSE;
}
int nResponse = dlg.DoModal();一句使你的整个程序都在DoModal()内部进行。而且,你退出DoMal()时[你一定结束了你的对话框],InitInstance返回的是False,我们知道,这样,CwinThread::Run是不会执行的。
但对话框程序是在哪里进行消息处理的呢。
原来,dlg.DoModal()内部会调用CwinThread::RunModalLoop,它起到的作用和RUN()是一样的[当然内部有细小差别,请参考MSDN]!!!
第二种情况,你是在SDI[或其它]程序中调用Dlg.DoModal() 产生了一模式对话框[有父窗口].
这又是如何运作的呢?
建了这样一个工程做为例子。
SDI,在View中处理LBUTTONDOWN:
MyDLg.DoModal();
MyDLg内有按钮,以惫后用.
没有显示模式对话框前,消息处理一直在Cthread::Run()中进行.
你单击后,程序执行点进入DoModal()内部的RunModalLoop,这又是一个消息处理机制.
不过DoModal()中调用RunModalLoop,前会Disable掉它的父窗口.从RunModalLoop中出来后,再 Enable它.
模式对话框和非模式对话框都是通过调用CreateDialogIndirect()产生创建对话框.那它和非模式对话框区别是什么造成的呢?
1 模式对话框将父窗口DISABLE掉.
我 原以为被Disable的窗口是不接收消息的.但后来我马上发现我是错的.但,为什么你对被Disable的窗口进行KeyBorad,Mouse动作 时,窗口没反映呢,我想,这可能是操作系统从中搞的鬼.我在本文一开始,就写出操作系统向窗口发送消息的过程,我想当它发现目标窗口处理Disabled 状态时,不会将消息发送给它,但这不能说窗口不接收消息,其它程序[或它本身]发送给它的消息还是可以接收并处理的.
2 模式对话框本身有消息处理机制 RunModalLoop.
对以上两点加以实验.
我在我的刚才建的项目中的模式对话框中加上一个BUTTON,其中加入如下代码:
OnButton1()
{
GetParaent()->EnableWindow(1);
}
单击,后我们发现,此时它已经不再表现为”模态”,我试着点击菜单,还是会作出正常反映.
我想这此消息[对于父窗口的,如:菜单动作]的处理也应是在模式对话框中的RunModalLoop中进行处理的吧[这点我不能确定].
先写到这里吧,一点浊见.请大家批评.
分享到:
相关推荐
### 深入剖析MFC中Windows消息处理机制 #### Windows消息处理机制概述 Windows程序设计的核心在于消息处理机制。消息处理是Windows操作系统的核心部分,它使得程序能够响应用户的输入和其他事件。当用户与应用程序...
《剖析Windows的消息运行机制》 Windows操作系统以其丰富的系统资源和强大的功能,吸引了众多开发者使用各种开发工具,如Visual C++、Visual Basic、Delphi、C++ Builder等,创建基于其平台的应用程序。无论使用何...
### MFC程序运行机制深入解析 #### 一、MFC程序框架的核心——WinMain入口 在探讨MFC程序运行机制之前,我们先聚焦于MFC程序的起点:`WinMain`函数。MFC(Microsoft Foundation Classes)是微软提供的一系列C++...
要想熟练掌握 Windows 应用程序的开发,首先需要理解Windows 平台下程序运行的 内部机制。市面上很多介绍Visual C++开发的书籍...部运行机制,为读者扫清VC++学习路途中的第一个障碍,为进一步学习MFC 程序打下基 础。
感谢网络前辈的无私分享,再整理一下 WTL 的学习文档。 所有源码都能在 VC6,WTL7.0 下编译通过。 具体内容如下: 1、WTL个性设置demo 文档和源码。...10、深入剖析MFC中对于Windows消息处理、运行机制.doc
消息映射是MFC中处理用户输入和系统事件的核心机制。MFC使用宏定义消息映射表,将特定的消息与相应的处理函数关联起来。当消息被发送到窗口时,MFC会自动调用相应处理函数,这样简化了消息处理代码的编写。 消息...
这个压缩包中的“浅析MFC程序基本运行机制.pdf”文档,很可能是对MFC运行机制的深入解析,对于初学者来说是一份宝贵的资源。 MFC的核心理念是封装Windows API,它将复杂的Win32编程接口包装成易于理解和使用的C++类...
本文将深入剖析MFC的源码,揭示其内部结构和工作原理。 #### MFC程序的基本结构 MFC应用程序的核心在于它的框架结构,这包括了初始化、窗口创建、消息循环等关键步骤。在传统的C/SDK编程中,这些步骤都是显而易见...
《Visual C++权威剖析--MFC的原理、机制与开发实例》是一本深入解析MFC框架的书籍,它涵盖了C++的关键语法以及其在MFC中的应用,特别关注了MFC的核心机制。以下是对书中主要知识点的详细阐述: **第1篇 C++关键语法...
本文将深入剖析MFC的六大关键技术,包括初始化过程、运行时类型识别(RTTI)、动态创建、永久保存、消息映射以及消息传递。 **1. MFC程序的初始化过程** MFC程序的初始化过程是程序启动后首先执行的一系列操作,...
书中还应当详细介绍了MFC程序的启动和运行机制,包括MFC应用程序的入口点、消息循环的建立以及窗口的创建和消息的处理等。这对于理解Windows编程来说是至关重要的,也是学习Visual C++和MFC时无法绕过的基础知识点。...
同时,MFC使用消息映射机制来处理Windows消息,这使得消息处理更加简洁和灵活。 4. **控件与对话框**:MFC提供了大量的控件类,如CButton、CEdit、CListBox等,这些类对应于Windows API中的各种控件。对话框在MFC中...
第3章 MFC中的消息处理 CCmdTarget和消息映射表 窗口消息 MFC消息映射内幕 MFC如何使用消息映射表 进入消息循环:PreTranslateMessage() 结语 第4章 MFC实用类 简单值类型 MFC的集合类 CFile家族:MFC对文件的访问 ...
这本书通过深入剖析MFC的内部机制,帮助读者理解和掌握Windows编程的核心概念。源代码是学习MFC不可或缺的部分,因为实际操作代码能够提供更直观的理解,增强学习效果。 源代码文件通常包含了书中各个章节的示例...
通过对MFC源代码的深入分析,我们可以清晰地了解到MFC程序的基本结构及其背后的运行机制。尽管MFC封装了许多底层细节,但通过理解上述关键概念,开发者仍然能够掌握如何构建高效且可扩展的Windows应用程序。
首先,书中详细介绍了MFC的基本架构,包括类库的组织结构、消息处理机制以及MFC与Windows API的关系。MFC将Windows编程中的核心概念如窗口、消息、控件等抽象为一系列的C++类,使得开发者可以通过面向对象的方式来...
《MFC六大核心机制解析——以程序...随着对MFC其他五大核心机制——运行时类型识别(RTTI)、动态创建、永久保存、消息映射和消息传递的深入学习,我们将能更全面地掌握MFC的精髓,从而更高效地构建Windows应用程序。
本书基于对MSDN(Microsoft Developer Network)的广泛研究和对MFC源代码的深入剖析,为读者揭示了MFC的工作原理和设计模式。MFC的主要目标是简化Windows应用程序的开发,它将Windows编程中的许多底层细节抽象成了...
在本书中,作者深入剖析了MFC的设计理念和实现机制,旨在帮助读者全面理解MFC的内部结构,从而能够更高效、更有针对性地利用这一工具进行软件开发。第二版通常会包含第一版中反馈的问题修复,以及新的特性和技术更新...