MFC DLL PreTranslateMessage caused by shortcut keys not responding to the problem?

Workaround:

Http://blog.sina.com.cn/s/blog_53d9f7e901000aef.html

Http://zhidao.baidu.com/link?url=wl3LlUGz_oCQplgHV6vyf-c0dOsBW4xNa68dQJJL_ Kh1wcjaetedtvprlf3zgdxq3vkpkrkmhyyol02mw2vdgtbvrc-4pjuvpxdb_tnjsku

The method is posted on it and verified by itself.

But this article says not to solve the problem of the method, but to say why MFC use PreTranslateMessage reason!

The story begins: Recently in the video player interface, interface with DUILIB development, the interface is all encapsulated in the DLL, found unable to filter shortcut keys, then did not think why? , the problem is, the window message will only send the corresponding window processing function inside to go, then how do I in a window unified processing it? This time I want to use the keyboard hooks to deal with. Directly with the hook keyboard hook to get the key message, analogy to enter full screen, space tentative. Think back in fact think PreTranslateMessage actually do the same thing, if you have feelings, you think carefully you will find out why MFC has a afxmaphwnd this thing, because the entire window HWND to save the list.

Because the HWND is just a window handle, it doesn't work, and we handle everything in the window class, so we get the corresponding entity class through Afxmaphwnd.

Say this much, I say things directly in code,

For our window core message loop:

BOOL AFXAPI afxinternalpumpmessage () {_afx_thread_state *pstate = AfxGetThreadState (); if (!::getmessage (& pState- >m_msgcur), NULL, NULL, NULL) {#ifdef _debugtrace (traceappmsg, 1, "CWinThread::P umpmessage-received wm_quit.\n"); pstate->m_ndisablepumpcount++; Application must die#endif//note:prevents calling message loop things in ' exitinstance '//would never be decrementedre Turn FALSE;} #ifdef _DEBUG  if (pstate->m_ndisablepumpcount! = 0) {  TRACE (traceappmsg, 0, "Error:cwinthread::P umpmessage Called when not permitted.\n ");  ASSERT (FALSE);} #endif #ifdef _debug_afxtracemsg (_t ("PumpMessage"), & (Pstate->m_msgcur)); #endif  //process this Messageif (Pstate->m_msgcur.message! = Wm_kickidle &&! Afxpretranslatemessage (& (Pstate->m_msgcur))) {:: TranslateMessage (& (Pstate->m_msgcur));::D Ispatchmessage (& (Pstate->m_msgcur));}  return TRUE;}

This code is similar to the Win32 code we often write.

Afxpretranslatemessage (& (Pstate->m_msgcur)

BOOL afxinternalpretranslatemessage (msg* pMsg) {//assert_valid (this); CWinThread *pthread = Afxgetthread (); if (pThread) {//If this was a thread-message, short-circuit this functionif (pmsg-> ; hwnd = = NULL && Pthread->dispatchthreadmessageex (PMSG)) return TRUE;} Walk from Target to main windowcwnd* pMainWnd = AfxGetMainWnd (); if (Cwnd::walkpretranslatetree (pmainwnd->  GetSafeHwnd (), PMSG)) return true;//in case of modeless dialogs, last chance route through main//   window ' s accelerator Tableif (pMainWnd! = NULL) {cwnd* pWnd = Cwnd::fromhandle (Pmsg->hwnd); if (pwnd->gettoplevelparent ()! = pMainWnd) re Turn pmainwnd->pretranslatemessage (PMSG);} return FALSE;   No special Processing}

BOOL PASCAL Cwnd::walkpretranslatetree (HWND hwndstop, msg* pMsg) {ASSERT (hwndstop = = NULL | |:: IsWindow (Hwndstop)); ASSERT (PMSG! = NULL);//walk from the target window, the Hwndstop window checking//  If any window wants to transl Ate this messagefor (HWND hwnd = pmsg->hwnd; hwnd = NULL; hwnd =:: GetParent (hwnd)) {cwnd* pWnd = Cwnd::fromhandleperma Nent (HWND); if (pWnd! = NULL) {//target window is a C + + windowif (pwnd->pretranslatemessage (PMSG)) return TRUE;//Trappe d by Target window (eg:accelerators)}//got to Hwndstop window without interestif (hWnd = = hwndstop) break; return FALSE;       No special Processing}

Cwnd::walkpretranslatetree (Pmainwnd->getsafehwnd (), PMSG)

FromPmsg->hwnd

Deal with this message, if you do not handle, will dad window processing, Dad window does not handle, will Grandpa window processing, if not return false, additional code block processing.

If the window class is actually in the exe inside this will be handled normally. But inside the DLL,

cwnd* pWnd = cwnd::fromhandlepermanent (hWnd); The code will be problematic because MFC is separate from the modules. Analogy DLL1 is Module 1 DLL2 Module 2 EXE is also another module. Each module has its own list of window classes ... So I can not traverse into the windows of your DLL in EXE. That's why you can't run.

</pre><p></p><p></p><p> <pre name= "code" class= "CPP" > Afxinternalpretranslatemessage

In case of modeless dialogs, last chance route through main//   window ' s accelerator tableif (pMainWnd! = NULL) {CWnd * PWnd = Cwnd::fromhandle (Pmsg->hwnd); if (pwnd->gettoplevelparent ()! = pMainWnd) return pmainwnd->pretranslatemessage (PMSG);}

If the above is still not processed, the detection of this window is not ws_child window, then find his own window to deal with.

If there is no attribution to find the top-level window processing, anyway, MFC will try to find a suitable window to deal with, always find a suitable to deal with.

Look at the code or frame code, some code details code look really tired, I now see Chromuni code really new feeling a little tired. Or find your own module of interest to see it.

In fact, the above book so much, summary is MFC each module Save window list module, each module independent.

______________________________________________________________________________________________

What if my pure Win32 to write such a pretranslatemessage way function? I do not use the list, in the HWND to create a binding data structure, if the C + + binding a window C + + class, if the C. Binding a C pointer, so that there is no problem with the above module, but to consider the problem of thread competition. So why does MFC have to Thread independent, module independent reason. Once multi-threading comes in, a lot of things are out of control.

MFC DLL PreTranslateMessage caused by shortcut keys not responding to the problem?