WM_CHAR消息分析

WM_CHAR消息分析

责任编辑：admin 　 更新日期：2005-8-6

下载本文所附源代码 应用程序中键盘消息从WM_KEYFIRST到WM_KEYLAST那么多，但我们知道最原始的键盘消息只有两个那就是WM_KEYDOWN,WM_KEYUP,在键盘钩子中我们能截获的也就这两个消息，那其它消息是从何产生的，如何动作的呢？下面我们就WM_CHAR消息来分析一下。 一个键按下后，便会有一个或多个WM_KEYDOWN消息产生，这些消息会从系统消息队列发送到目标窗口的线程的消息队列中，这样在对应线程处理消息时便会对此消息处理，并在处理的过程中产生一系列的其它键盘消息,其中便有WM_CHAR。 以下是向对话框中的编辑框输入'a'的部分处理过程（以所附源码调试、整理而得） CGetInputDlg::DoModal()　　　　　//对话框创建 往编辑框按下一键'a' 001 CGetInputDlg::RunModalLoop //消息循环，在这里peek到WM_KEYDOWN 002 CGetInputDlg::PumpMessage　//消息泵，取消息、翻译、处理这些消息 003 CGetInputDlg::PreTranslateMessage　//线程开始消息预处理 004 CGetInputDlg::WalkPreTranslateTree　//从目标窗口到主窗口历遍 005 CMyEdit::PreTranslateMessage　　　　//目标窗口，没有处理（返回FALSE）。 006 CGetInputDlg::PreTranslateMessage　//子窗口没有处理，所以流到父窗口 007 CDialogDlg::PreTranslateMessage　//由基类处理 　　 ... 008 CMyEdit::WindowProc 009 CMyEdit::OnWndMsg 010 CMyEdit::OnKeyDown 011 CMyEdit::DefWindowProc 012 CGetInputDlg::RunModalLoop //在这里peek到WM_CHAR，不过一般情况下之间会有几个WM_KICKIDLE 　　　 ... 由上有人就会说，这并不能说明WM_CHAR是WM_KEYDOWN消息处理过程中产生的，这仅仅说明WM_CHAR在WM_KEYDOWN之后。i嗯，大家再看看下面。 这些是所附源码中的调试输出信息，无~~代表对应函数的进入，有~~代表一个函数的返回点，msg后的值为消息的16进制值(WM_KEYDOWN=0X100, WM_KEYUP=0X101, WM_CHAR=0X102)，haveCharMsg为消息队列中是否有WM_CHAR消息（通过peekmessage来实现） 英文输入'a'，对应调试信息整理如下： 对应005 101　CMyEdit::PreTranslateMessage msg=100, haveCharMsg=0 102　~~CMyEdit::PreTranslateMessage msg=100, haveCharMsg=0, Ret=0 对应006 103　CGetInputDlg::PreTranslateMessage msg=100, haveCharMsg=0 105　 CMyEdit::OnKeyDown haveCharMsg=1 106　 CMyEdit::DefWindowProc msg=100, haveCharMsg=1 107　 ~~CMyEdit::DefWindowProc msg=100, haveCharMsg=1, Ret=1 108　 ~~CMyEdit::OnKeyDown haveCharMsg=1 109　~~CGetInputDlg::PreTranslateMessage msg=100, haveCharMsg=1, Ret=1 110　CMyEdit::PreTranslateMessage msg=102, haveCharMsg=0 111　~~CMyEdit::PreTranslateMessage msg=102, haveCharMsg=0, Ret=0 112　CGetInputDlg::PreTranslateMessage msg=102, haveCharMsg=0 113　 CMyEdit::OnChar 61 114　 CMyEdit::DefWindowProc msg=102, haveCharMsg=0 115　 ~~CMyEdit::DefWindowProc msg=102, haveCharMsg=0, Ret=1 116　 ~~CMyEdit::OnChar 61 117　~~CGetInputDlg::PreTranslateMessage msg=102, haveCharMsg=0, Ret=1 118　CMyEdit::PreTranslateMessage msg=101, haveCharMsg=0 119　~~CMyEdit::PreTranslateMessage msg=101, haveCharMsg=0, Ret=0 120　CGetInputDlg::PreTranslateMessage msg=101, haveCharMsg=0 121　 CMyEdit::OnKeyUp 122　 CMyEdit::DefWindowProc msg=101, haveCharMsg=0 123　 ~~CMyEdit::DefWindowProc msg=101, haveCharMsg=0, Ret=0 124　 ~~CMyEdit::OnKeyUp 125　~~CGetInputDlg::PreTranslateMessage msg=101, haveCharMsg=0, Ret=1 看到了吗？在103处（对应处理过程006处）的CGetInputDlg::PreTranslateMessage里产生了WM_CHAR消息，并放入了消息队列中。由此可见消息确实是WM_KEYDOWN处理过程中产生的。在WM_KEYDOWN处理完成后，消息循环便检测到它，并在PumpMessage中Get它，并进入110相应的处理。也就在此时队列中已无WM_CHAR消息了。 耶，不对啊，很多地方不是说TranslateMessage产生WM_CHAR消息？他们的意思也就是PumpMessage中的 ::TranslateMessage(&m_msgCur)，我将PumpMessage简化如下： 200 BOOL CWinThread::PumpMessage()　(CGetInputDlg::PumpMessage) 201 { 202 ASSERT_VALID(this); 203 if (!::GetMessage(&m_msgCur, NULL, NULL, NULL)) 204 return FALSE; 205 // process this message 206 if (m_msgCur.message != WM_KICKIDLE && !PreTranslateMessage(&m_msgCur)) 207 { 208 ::TranslateMessage(&m_msgCur); 209 ::DispatchMessage(&m_msgCur); 210 } 211 return TRUE; 212　} 这里可见，只有当PreTranslateMessage（CGetInputDlg::）返回FALSE时才会执行208处对应的函数，而事实上从103处可以看到CGetInputDlg::PreTranslateMessage还没有返回，就有了WM_CHAR消息，而且从~~CGetInputDlg::PreTranslateMessage可以看出PreTranslateMessage返回为1，不会执行208、209。那是不是那些说法错了呢? 也不一定，如果他指的是对话框程序，那我想他就确实错了，但对于非对话框程序是对的，我建了一SDI工程，PreTranslateMessage中对于非加速键返加是FALS，即会执行208、209。::TranslateMessage(&m_msgCur)来翻译键盘消息。当然，如果我想PreTranslateMessage中的默认处最终还是调TranslateMessage来完成翻译的，只是不对应208处的代码而己。 到此以也就差不多了，但点要提醒大家，如果你在验证这些时，在某些函数中设了断点（如OnKeyDown)，然后按键输入，这时会停在断点处，然后你再运行，这时会得出某些不一样的结果。主要是WM_KEYUP消息没有了，因为收到WM_KEYUP消息的窗体为调试器。