Win32 C/C++ - Modal 메시지 루프 내에서 SetWindowsHookEx를 이용한 Thread 메시지 처리 방법
스레드 메시지는 PostThreadMessage를 이용해서 발생시킬 수 있는데요,
BOOL PostThreadMessageW(
[in] DWORD idThread,
[in] UINT Msg,
[in] WPARAM wParam,
[in] LPARAM lParam
);
보는 바와 같이 대상 스레드, 즉 메시지 루프를 돌고 있는 스레드의 ID를 이용해 메시지를 (Send가 아닌 Post로) 전송하는 방식입니다. 그런데, 사실 일반적인 메시지 루프에서는 PostThreadMessage로 전송한 메시지는 처리되지 않습니다. 그 이유를 아래의 글에서 설명하고 있는데요,
Thread messages are eaten by modal loops
; https://devblogs.microsoft.com/oldnewthing/20050426-18/?p=35783
왜냐하면, 아래와 같이 구현한 메시지 루프의 경우,
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
DispatchMessage는 msg.hwnd 필드에 지정한 윈도우로 메시지를 전송하는 것만 하기 때문입니다. 따라서 인자로 윈도우 핸들이 아닌 스레드 ID를 받는 PostThreadMessage로 전송하게 되면 msg.hwnd는 null이 되고 결국 그 메시지를 수신하는 Window Procedure가 없기 때문에 당연히 메시지 처리가 안 됩니다.
결국, 이에 대한 해결책으로 내놓는 것은,
Watching thread messages disappear
; https://devblogs.microsoft.com/oldnewthing/20050427-10/?p=35763
BOOL IsThreadMessage(MSG *pmsg)
{
if (pmsg->hwnd == NULL) {
switch (pmsg->message) {
case WM_APP: MessageBeep(-1); return TRUE;
}
}
return FALSE;
}
...[함수 생략]...
while (GetMessage(&msg, NULL, 0, 0)) {
if (!IsThreadMessage(&msg)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
PostThreadMessage로 전송한 메시지를 별도로 처리하는 코드를 GetMessage 다음에 넣어두는 정도에 불과합니다. (실제로
제가 예전에 소개한 콘솔 응용 프로그램용 메시지 루프도 그런 식으로 구현됐습니다.)
하지만, 이런 노력이 물거품이 되는 순간이 있습니다. 바로 Modal 대화창을 띄운 경우인데요, 당연히 (그 어느 누가 임의로 구현했을) modal 메시지 루프에서는 PostThreadMessage 메시지 처리에 대한 배려가 전혀 없으므로 (사실 배려할 수도 없으므로) 그런 경우에는 동작하지 않게 됩니다.
물론, 공식적으로 Modal 메시지 루프의 경우에도 PostThreadMessage로 전송한 메시지를 처리할 수 있는 방법이 제공됩니다. 바로 아래의 글에서 소개하고 있는데요,
Rescuing thread messages from modal loops via message filters
; https://devblogs.microsoft.com/oldnewthing/20050428-00/?p=35753
방법은
SetWindowsHookEx을 이용해 WH_MSGFILTER 대상의 훅을 걸어 두는 것입니다.
HHOOK g_hhkMSGF;
LRESULT CALLBACK MsgFilterProc(int code, WPARAM wParam, LPARAM lParam)
{
MSG* pmsg = (MSG*)lParam;
if (code >= 0 && IsThreadMessage(pmsg)) return TRUE;
return CallNextHookEx(g_hhkMSGF, code, wParam, lParam);
}
BOOL OnCreate(HWND hwnd, LPCREATESTRUCT lpcs)
{
g_hhkMSGF = SetWindowsHookEx(WH_MSGFILTER, MsgFilterProc, NULL, GetCurrentThreadId());
if (!g_hhkMSGF) return FALSE;
...
}
엄밀히 말해서 WH_MSGFILTER 옵션은 협업에 의한 메시지 후킹 처리를 하는 것인데요, 설명을 보면,
The WH_MSGFILTER hook can only monitor messages passed to a menu, scroll bar, message box, or dialog box created by the application that installed the hook procedure.
Window Manager가 구현한 요소에서만 후킹이 되는 것으로 나옵니다. 왜냐하면, 이런 요소들이 생성한 메시지 루프는, 달리 말해 마이크로소프트가 작성한 Modal 메시지 루프는 반드시 CallMsgFilter를 호출하도록 작성했기 때문입니다.
MSG msg;
while (GetMessage(&msg, NULL, 0, 0)) {
if (!CallMsgFilter(&msg, MSGF_MYLIBRARY)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
/*
MSGF_MYLIBRARY는 임의의 식별자에 불과하며 다른 예로 commctrl.h에 정의된 상수들이 있습니다.
이 값들은 SetWindowsHookEx로 설치한 후킹 함수의 첫 번째 인자로 전달받게 됩니다.
#define MSGF_COMMCTRL_BEGINDRAG 0x4200
#define MSGF_COMMCTRL_SIZEHEADER 0x4201
#define MSGF_COMMCTRL_DRAGSELECT 0x4202
#define MSGF_COMMCTRL_TOOLBARCUST 0x4203
*/
저렇게 CallMsgFilter가 호출되는 경우에만 SetWindowsHookEx/WH_MSGFILTER로 걸어둔 후킹 메시지가 실행되기 때문에 PostThreadMessage로 전송한 메시지를 처리할 수 있는 기회를 얻게 되는 것입니다.
물론, 위의 방법에도 단점이 있습니다. 일단 마이크로소프트가 만든 Modal 메시지 루프는 전부 CallMsgFilter를 호출하고 있지만, 그렇지 않은 메시지 루프를 갖고 있는 3rd-party 라이브러리도 있을 것이기 때문입니다.
어쩔 수 없습니다. 그런 경우까지 모두 고려해야 한다면 (WH_MSGFILTER가 아닌) WH_GETMESSAGE 옵션으로 SetWindowsHookEx를 설치해야 합니다. 그렇게 되면 GetMessage API 호출 시마다 후킹 함수가 실행돼 자연스럽게 모든 문제가 해결됩니다. 여기서 주의할 것은, Modal Message Loop에서만이 아닌, 기본적으로 모든 메시지에 대한 후킹을 하게 되는 것이므로 부하가 더 커진다는 점입니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]