김 용묵의 절대공간 - 블로그

1. 테두리

GUI 프로그램에서 대화상자를 만들다 보면 단순히 글과 그림, 목록, 버튼 같은 것만 집어넣는 게 아니라 그 컨트롤들을 성격별로 분류하는 구획 경계선, 테두리 같은 걸 그어야 할 때가 있다.
그런 게 필요하면 static 컨트롤을 쓰면 된다. Visual C++의 리소스 에디터 상으로는 Static text와 Picture control이 서로 다른 항목으로 나뉘어 있지만, 둘 다 운영체제의 윈도우 클래스 이름은 동일하게 "Static"이다.

Picture 컨트롤을 삽입한 뒤 속성에서 Type을 Etched Vert으로 고르면 세로줄이 만들어지며, Etched Horz를 고르면 가로줄이 만들어진다. 그리고 Type을 Frame으로 지정하고 Color를 Etched로 지정하면 사각형 테두리를 만들 수 있다.
선을 단순히 단색으로 그리는 게 아니라 음각으로 파인 듯이 3D 입체 효과(?)가 나게 그리기 때문에 etched라는 단어가 자꾸 나온다.

그런데 Picture 컨트롤만 있는가 하면 그렇지는 않다. 우리가 잘 아는 Group box라는 컨트롤도 있어서 사각형 테두리를 친다는 점에서는 Picture하고 거의 같은 역할을 한다.
단, Group box는 테두리의 좌측 상단에 간단한 텍스트를 찍을 수 있다. 그래서 이 테두리 안에 속한 컨트롤들의 전체 제목이나 카테고리 이름을 넣을 수 있기 때문에 더 유용하다.

또한, 이런 이유로 인해 Group box는 테두리의 윗변은 무작정 맨 위쪽이 아니라, 그 텍스트의 중앙 라인에 맞춰서 그어진다. 아래 그림을 보면 이게 무슨 말인지를 알 수 있다. (크기가 서로 동일한 Group box와 Picture frame이 화면에 실제로 보이는 형태)

Group box는 말 그대로 한 그룹에 속하는 컨트롤들(특히 라디오/체크 박스)의 가로· 세로 경계선과 제목 텍스트까지 한큐에 표시해 주기 때문에 굉장히 유용하다. 그런데 프로그램들에 따라서는 static text 옆에다가 가로줄 하나만 추가해 넣어서 Group box의 간소화 버전인 일종의 Group line을 넣기도 한다. 이 역시 위의 그림에 형태가 묘사되어 있으며, 독자 여러분도 이런 GUI를 많이 보신 적이 있을 것이다.

본인은 새로운 대화상자를 디자인할 때 Group box를 쓸지 Group line을 쓸지를 종종 고민하곤 한다. 가끔은 line이 box보다 더 깔끔하게 느껴질 때도 있다. line은 추가적인 좌우 여백을 소모하지 않기 때문에 공간 활용면에서도 좋다.

하지만 line은 group과는 달리, 텍스트와 가로줄을 서로 폭을 정확하게 계산해서 그려 주는 컨트롤이 없기 때문에 만들기가 불편하다. static text 따로, 가로줄 따로 두 컨트롤을 일일이 만들어야 한다. 텍스트의 글꼴이나 내용이 바뀌면 가로줄의 위치와 길이도 프로그램이 수동으로 업데이트해야 하니 번거롭다.

개인적인 생각은 (1) 길쭉하게 만들어 놓은 static 컨트롤에다가 텍스트를 찍은 뒤 나머지 오른쪽 여백에다가는 글자 크기 기준으로 중앙에 etched 가로줄을 자동으로 그려 주는 옵션을 추가하거나, (2) 기존 group box 컨트롤에 사각형 테두리가 아니라 가로줄만 찍는 옵션이 좀 있어야 한다고 본다. group box를 크기를 줄인다고 해서 group line로 만들 수는 없기 때문이다.

하지만 어느 것도 갖춰져 있지 않기 때문에 심지어 마소에서 만드는 프로그램들도 대화상자를 Spy++로 들여다보면 Group line은 별 수 없이 텍스트+가로줄로 수동으로 구현돼 있다. 아쉬운 점이 아닐 수 없다.
그래서인지.. MS Office 제품 중에서 운영체제의 대화상자를 사용하지 않고 자체 GUI를 사용하는(너무 역사가 길어서) Word와 Excel은 서식 대화상자 같은 걸 보면 group line이 상대적으로 많이 쓰였고, PowerPoint, Access, Publisher처럼 상대적으로 늦게 개발된 프로그램들은 group box를 더 많이 볼 수 있다.

내 심증은.. Word와 Excel은 한 개체만으로 간단하게 제목과 가로줄까지 group line을 표시해 주는 GUI 컨트롤/위젯을 자체적으로 보유하고 있는 것으로 보인다. 그 증거로는 Excel과 PowerPoint의 '화면 확대 배율' 대화상자 스크린샷이다. PowerPoint는 진짜 운영체제의 static 컨트롤 가로줄이지만 Excel은 그게 아니기 때문에 가로줄의 색깔이 두 프로그램이 서로 다른 걸 알 수 있다.

같은 제품 안에도 프로그램끼리 이렇게 미묘하게 일관성이 없는 부분이 존재한다.
그 뿐만이 아니다. 고전 테마에서는 group box의 선 모양과 static 컨트롤의 etched 선이 저렇게 똑같지만, 다른 테마가 적용되고 나면 둘의 선 모양이 달라진다. XP 시절의 Luna 테마든, 그 뒤의 Aero든.. 마찬가지다. 어느 것이든 group box의 선이 통상적인 etched 선보다 더 연해진다.

더욱 놀라운 사실은 따로 있다. 사실 group box는 윈도우 클래스가 Static이 아니라 Button이다. 이 정도로 Static 컨트롤과는 애초부터 기술적인 연결 고리가 없었다.
check나 radio 버튼은 비록 push 버튼과는 성격이 다르지만 그래도 BN_CLICKED라는 이벤트를 날려 준다는 공통점이 있으니 같은 버튼이라는 게 이해가 된다만.. group box는 포커스도 안 받고 이벤트도 없고.. 버튼과는 하등 공통점을 찾을 수 없는 static 장식품에 불과한데 도대체 왜 얘까지 Static이 아닌 버튼 소속인 걸까?

(더구나 라디오 버튼의 소속을 분류하는 것도 그 컨트롤들이 자체적으로 갖고 있는 WS_GROUP 스타일로 하지, 딱히 group box가 기여하는 건 없다. group box 안 만들어도 "1~3 중 택일, 4~7 중 택일" 같은 라디오 버튼들의 선택 영역 구분은 얼마든지 할 수 있다.)

Windows에서는 같은 버튼이라는 클래스인데 스타일을 무엇을 주느냐에 따라서(BS_GROUPBOX) 외형과 동작이 완전히 다른 윈도우가 되는 것이다. 먼 옛날 1.0 시절에는 리소스가 하도 부족해서 기본 윈도우 클래스를 새로 등록하는 것조차도 부담스러워서 가능한 한 같은 클래스에다가 여러 기능을 구겨넣기라도 해야만 했는가 보다. 하지만 group box가 왜 버튼 출신이며 기존 etched 선과 괴리가 생겼는지는 여전히 내 머릿속에 이해되지 않는 의문으로 남아 있다.

2. 버튼

말이 나왔으니 다음으로 버튼 얘기를 더 계속해 보도록 하자.
아래 그림은 평범한 라디오/체크/푸시 버튼과 탭 컨트롤을 고전 테마 기준으로 집어넣어 표시한 모습이다.

그런데, 라디오와 체크 버튼은 Button 출신답게 자기 자신도 버튼처럼 표시되게 하는 옵션이 있다. 바로 BS_PUSHLIKE 스타일. (BS_PUSHBUTTON은 윈도우의 동작 자체를 푸시 버튼으로 결정하는 스타일이니 혼동하지 말 것.)

저렇게 하니 라디오/체크도 푸시 버튼과 외형이 거의 똑같아진다. 그래도 키보드 포커스를 받았을 때 라디오/체크 버튼은 푸시 버튼처럼 테두리가 굵어진다거나 하지는 않기 때문에 실제로 조작해 보면 푸시 버튼과는 뭔가 다른 게 느껴진다.
라디오와 체크 버튼은 자신이 클릭된 경우 자신이 눌러지고 선택된(체크된) 상태로 바뀌는 반면, 진짜 푸시 버튼은 선택된 상태 같은 건 존재하지 않는다. 눌러도 다시 도로 튀어 올라온다는 차이점이 있다.

한편, 위의 그림에서 나오듯, 사실은 탭 컨트롤도 경계선 없이 각각의 탭의 이름만을 버튼처럼 표시하는 옵션이 있다(TCS_BUTTONS).
탭 버튼은 라디오 버튼과 비슷하지만 키보드로 조작할 경우, 화살표 키만 누른다고 해서 선택이 바로 이동하지 않는다. Space를 눌러서 선택을 확인해 줘야만 바뀐다는 차이가 있다.

도대체 이런 기능이 왜 존재하나 싶겠지만, 이 물건은 우리에게 아주 친숙하다. 먼 옛날, Windows 95의 작업 표시줄이 바로 탭 컨트롤에다가 이 스타일을 써서 구현돼 있었다. 물론 지금이야 작업 표시줄은 독자적인 비주얼과 기능이 너무 많이 들어갔기 때문에 진작에 자체 구현으로 바뀌었다.

이로써, 푸시 버튼처럼 생긴 놈이 푸시 버튼 자체뿐만 아니라 최소한 세 종류가 더 있을 수 있다는 뜻인데..
얘들도 테마를 변경하면 사정이 좀 달라진다.
Button들은 테마가 적용되어 버튼이 알록달록하게 바뀌지만 탭 컨트롤의 버튼들은 변화가 없다. 작업 표시줄 말고는 딱히 쓸 일이 없어져서 그런 듯하다. 글쎄, MDI 에디터 같은 데서 문서 탭을 나타낼 때 쓸 수도 있지 않으려나 모르겠다만..

이로써 버튼이 전혀 아니지만 클래스가 Button인 놈(group box), 버튼처럼 생겼지만 버튼이 아닌 놈(탭 버튼)을 모두 살펴보았다.
Windows XP~7이라는 과도기를 거쳐 8~10까지 나온 마당에 이제 운영체제에서 고전 테마는 더욱 보기 어려워지고 마치 XP Luna만큼이나 역사 속으로 사라져 가고 있다.
하지만 지금 생각해 봐도 고전 테마는 단순하면서도 굉장히 철저한 원칙 하에 세심하게 디자인된 것 같다. 화면에 표시만 하는 놈은 회색, 사용자와 interation을 하는 부분은 흰색에다가 두꺼운 입체 테두리, 포커스를 받은 아이템은 점선, 실제로 선택된 아이템은 highlight 색 등등..

그렇게도 사용자 감성, 인터페이스를 중요시한다면서 애플 맥 진영은 옛날에 GUI가 어떠했나 모르겠다. 안 그래도 마소가 애플의 GUI를 베꼈다고 험담이 많이 나돌던데.
그렇게 고전 테마 때 일관되게 형성되었던 GUI 가이드라인이 오히려 테마가 적용되면서, 당장 겉으로 드러나는 비주얼은 더 화려해졌을지 모르나, 그런 질서가 좀 무너진 듯한 것도 보여서 아쉬움이 남는다. 아무래도 고전 테마를 처음 만들던 때와 지금, 개발자가 세대 교체가 돼서 그런 것일 수도 있고.
그나저나 group line은 세대를 초월하여 진짜로 운영체제 차원에서 기능이 좀 있었으면 좋겠다.;;

Posted by 사무엘

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 사무엘