Windows 프로그래밍의 관점에서 볼 때 대화상자는 참 독특하면서도 중요한 위상을 차지하는 GUI 구성요소이다.
대화상자에는 누구나 공통으로 갖추고 있어야 하는 동작과 처리가 있으면서 한편으로 각종 자식 컨트롤로부터 notification을 처리하는 건 대화상자마다 제각각 customize가 가능해야 한다.
그래서 대화상자 함수는 customization을 위해 사용자가 작성한 대화상자 메시지 처리 콜백 함수를 인자로 받는다. 그리고 WM_SETICON 같은 메시지를 통해 아이콘조차도 클래스 차원이 아니라 윈도우 메시지 차원에서 필요하다면 변경할 수 있게 해 놓았다.
그럼 custom 프로시저가 가로채지 않은 나머지 공통 처리들은.. 마치 DefWindowProc처럼 DefDlgProc 같은 대화상자 윈도우 프로시저를 호출하는 것만으로 전부 가능해야 할 것 같지만, 사실은 그렇지 않다. Alt+단축키 처리, 그리고 포커스 이동 시에 '확인' 같은 default 버튼의 비주얼을 바꾸기 같은 것은 대화상자 윈도우 자체가 메시지를 받는 게 아니라 각 child 컨트롤들이 키보드 메시지를 받고 있을 때 그걸 가로채서 해치워야 한다. 대화상자 윈도우가 무슨 훅킹이라도 하고 있지 않은 이상 말이다.
이런 이유로 인해 대화상자의 동작을 위해서는 message loop 차원에서 메시지를 가로채는 로직이 필요하다. 그래서 IsDialogMessage라는 함수가 그 코드에 들어가야 한다. 물론 DialogBox 함수로 modal 대화상자를 만들었을 때는 해당 함수가 자체적으로 message loop을 돌리면서 그 처리를 당연히 알아서 해 주니, 저런 별도의 함수는 우리 쪽에서 modeless 대화상자를 운용할 때에나 필요하다.
사실 저 함수는 용도를 생각하면 Is..가 아니라 TranslateDialogMessage 정도로 작명이 됐어야 했다. 그래야 오해가 없다. 단순히 쿼리에 대한 판별값을 되돌리는 게 아니라 실제로 무슨 일을 수행하기 때문이다.
뭐, message loop은 그렇다 치고, 대화상자를 대상으로 생성된 메시지는 우리가 지정한 대화상자 프로시저 → 대화상자 자체의 윈도우 프로시저(DefDlgProc) → 운영체제가 제공하는 DefWindowProc 이런 순으로 메시지를 처리하게 된다. 앞 계층에서 처리하지 않은 메시지가 다음 계층으로 간다는 뜻이다.
C++이라면 이건 깔끔한 클래스의 상속 관계로 표현할 수 있을 것이다. 그러나 Windows가 처음 개발됐을 때는 C++이 쓰이지 않았었다. 그리고 결정적으로, 모종의 이유로 인해 대화상자 프로시저와 윈도우 프로시저는 형태가 미묘하게 서로 달라져서 온전한 일관성이 보장되지 않는다.
오리지널 윈도우 프로시저는 내가 메시지의 처리를 한다면 리턴값을 바로 되돌리면 되고, 내가 처리하지 않은 메시지에 대해서는 DefWindowProc()를 해 주면 된다.
return ret; //처리한 경우
return DefWindowProc(hWnd, msg, wParam, lParam); //처리하지 않은 경우
그러나 대화상자 프로시저는 자기가 이미 DefDlgProc라는 디폴트 처리 함수(= 대화상자의 원래 윈도우 프로시저)로부터 호출을 받은 구도이다. 이것이 디자인 상으로 가장 본질적인 차이점이다.
그래서 리턴값으로는 이 메시지를 우리가 처리했는지의 여부만을 BOOL 형태로 되돌리고, 메시지 리턴값은 따로 꽤 번거롭게 넣어야 한다.
SetWindowLongPtr(hDlg, DWLP_MSGRESULT, ret); return TRUE; //처리한 경우
return FALSE; //처리하지 않은 경우
저럴 거면 차라리 함수의 인자에다가 LRESULT *pnResult 같은 포인터를 추가해서 거기로 되돌릴 수 있게라도 하지 하는 아쉬움이 남는다.
*pnResult=ret; return TRUE; //처리한 경우 -- 대안 1
*pbEaten=TRUE; return ret; //처리한 경우 -- 대안 2
그런데, 대화상자 프로시저에도... 형태가 간단한 극소수의 예외적인 메시지는 리턴값을 SetWindowLongPtr이 아니라 일반 윈도우 프로시저처럼 자신의 리턴값으로 되돌린다. 그렇기 때문에 대화상자 프로시저는 대부분의 경우 TRUE/FALSE만을 되돌림에도 불구하고 리턴값이 쿨하게 BOOL이 아니라 INT_PTR로 지정되어 있다. LRESULT도 아니고 이거 참.. 지저분하다면 지저분하다.
그 예외로는 자식 컨트롤의 배경을 칠할 브러시를 되돌리는 WM_CTL*, owner-draw 컨트롤에서 아이템 간의 대소를 비교하는 WM_COMPAREITEM, 그리고 역시 owner-draw 컨트롤에서 아이템의 바로가기 key를 지정하는 WM_(CHAR/VKEY)TOITEM이 여기에 해당한다. COM 함수라고 해도 실패를 할 우려가 전혀 없고 리턴값도 BOOL 값 달랑 하나 같은 건 굳이 BOOL *pfResult라는 인자로 주기보다는 간단히 S_OK, S_FALSE라는 자기 리턴값으로 되돌리는 게 더 나은 것과 같은 이치이다.
그리고 저 예외 메시지들은 owner-draw처럼 애초에 custom 동작을 염두에 두고 만들어진 메시지이므로 default로 넘기느냐 마느냐를 따지는 게 전혀 무의미하다. 그러니 리턴값을 바로 직통으로 사용하는 것이 더 간편하고 낫다. WM_CTL*의 경우도 컨트롤을 서브클래싱할 때에나 쓰이니 이 역시 customization과 관계가 있다.
왜 저렇게 예외가 만들어졌는지 이제 이해는 되지만, 그래도 대화상자 프로시저의 인터페이스가 구리고 지저분하고 복잡해 보이는 건 어쩔 수 없는 사실이다. 그래서 대화상자 프로시저도 윈도우 프로시저와 비슷한 구조로 만들 수 있게 하는 일종의 코딩 디자인 템플릿이 있다. MFC 같은 C++ 프레임워크는 밑바닥에서 당연히 이런 일도 다 해 주고 있지만, C만 쓴다거나 MFC보다 더 가벼운 Windows API 프레임워크를 우리가 직접 만드는 상황이라면 그 내부 디테일을 알 필요가 있다.
기본적인 아이디어는 이렇다.
운영체제의 DefDlgProc는 우리 프로시저를 먼저 호출하여 메시지의 처리 여부를 묻는다. 우리 프로시저는 그 메시지를 처리한 경우라면 리턴값 + TRUE만 되돌리면 되니 끝이다. 그 반면 처리하지 않은 경우, 내부적인 재귀호출 플래그를 설정한 뒤 DefDlgProc을 또 호출한다.
그럼 DefDlgProc는 아까처럼 우리를 또 호출하는데, 이때 우리 프로시저는 이미 설정된 재귀호출 플래그를 보고는 비로소 더 처리를 하지 않는 FALSE를 되돌린다.
또한, 리턴값을 지정할 때 메시지 종류에 따라 곧이곧대로 리턴(일부 예외 메시지들)하거나 SetWindowLongPtr을 호출하는 것은 메시지 핸들러 말고 그 아래의 static 콜백 함수에서 하면 된다.
이 아이디어를 의사코드로 표현하면 다음과 같다.
class CMyDialog {
static INT_PTR CALLBACK DialogProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam);
BOOL m_bRecur;
protected:
virtual LRESULT DlgProc(UINT msg, WPARAM wParam, LPARAM lParam);
public:
CMyDialog(): m_bRecur(FALSE) { }
};
//클래스에서는 아마 private로 지정되어 있을 우리 대화상자 프로시저 callback.
INT_PTR CALLBACK CMyDialog::DialogProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam)
{
//HWND로부터 C++ 오브젝트 얻기. 훅킹을 해서 WM_NCCREATE를 잡든가 아니면 WM_INITDIALOG일 때
//hDlg와 C++ 오브젝트를 연결하는 작업을 할 것. 이 코드에서는 그걸 생략함
CMyDialog *obj = GetObject(hDlg);
//BOOL값. 저 값이 true이면 재귀 상태라는 뜻이므로 그걸 false로 바꾸고, 함수도 false로 종료.
CheckDefDlgRecursion(&obj->m_bRecur);
//msg가 예외에 속하면 리턴값을 바로 되돌리고, 아니면 SetWindowLongPtr로 리턴값을 지정해 줌.
return SetDlgMsgResult(hdlg, msg, obj->DlgProc(msg, wParam, lParam));
}
//각 클래스별로 오버라이드 하면 되는 가상 함수.
//윈도우 핸들은 우리 C++ 클래스의 멤버에 포함되어 있다고 가정함.
LRESULT CMyDialog::DlgProc(UINT msg, WPARAM wParam, LPARAM lParam)
{
//재귀호출 플래그를 켠 뒤에 DefDlgProc를 호출한다.
return DefDlgProcEx(m_hWnd, msg, wParam, lParam);
}
windowsx.h를 보면 SetDlgMsgResult, DefDlgProcEx, CheckDefDlgRecursion 같은 매크로 함수가 이런 디자인 패턴을 구현하라고 만들어진 물건들이다. 16비트 시절부터 있었고 MFC만큼이나 역사와 내력이 대단히 길다.
<날개셋> 한글 입력기는 지난 3.0때부터 GUI가 그냥 Windows API와 자체 제작 프레임워크를 사용해서 만들어졌지만, 그땐 본인은 이런 기법을 미처 생각하지 못했었다. 그래서 대화상자 프로시저들은 대충 return 1에 SetWindowLongPtr 등을 뒤죽박죽 섞어서 만들어져 있다. 그러나 저런 방법을 진작에 알았으면 대화상자 메시지 처리기도 마치 윈도우 프로시저 스타일로 일관성 있게 만들 수 있었겠다. 이제 와서 수많은 대화상자 프로시저들을 저 기준대로 고치는 것은 무의미한 지경이 됐지만 말이다.
Posted by 사무엘
