The old problem of modeless dialog keyboard navigation in a mfc dll...
I am having difficulties with enabling keyboard navigation (tab stop,
etc) in a CDialogBar created in a MFC Dll (with a CWinApp object).
After much research on MSDN and the net, I found that the reason is
that the Dll's CWinApp::PreTranslateMessage does not get called so
that I have to call it from the main application message pump. I build
my UI as a wrapper over an existing application, and I don't have the
code for it, so what I do is I hook onto the existing application's
message pump with a GetMsgProc callback, and from there I call the
CWinApp::PreTranslateMessage. If the Dll's CWinApp processes the
message, I consume it so that it does not come back through the window
LRESULT CALLBACK CMyHook::GetMsgProc(int code, WPARAM wParam, LPARAM
if (code >= 0)
LPMSG pMsg = (LPMSG) lParam;
// narrow the processing to the dialog key
if (wParam == PM_REMOVE &&
(pMsg->message >= WM_KEYFIRST &&
pMsg->message <= WM_KEYLAST)
// switch to the mfc context for the dll
// forward to the Dll application loop to
// allow keyboard navigation in the
// dialog bars
// if the message is processed by
// the dll application, consume it
pMsg->message = WM_NULL;
pMsg->wParam = 0;
pMsg->lParam = 0;
return CallNextHookEx(m_hWindowProcHook, code,
It works somehow, except for 2 things:
- When the focus is onto the dialog bar, if I open the main window
menu and try to navigate using the keyboard, the key event go to the
dialog bar instead of the menu.
- I am using the IME for Japanese characters and the Japanese
characters get mangled.
I think it is because no matter what, the PreTranslateMessage always
returns TRUE, even when it should not process the event.
I probably can work around that by filtering the events and monitoring
the menu events and such, but I have the feeling that there is
something I am doing wrong (or forgetting to do).
Any ideas ?