기반 클래스 준비

프로젝트 생성

예제 수준을 넘어서는 중대형 프로젝트를 작성할 때는 기반 클래스를 잘 만들어 두어야 한다. 객체를 조립하여 프로그램을 완성해 나가는 바텀업(Bottom Up) 방식에서는 객체가 안정적이고 튼튼해야 그 위의 프로그램도 제 기능을 십분 발휘할 수 있다. 기능적 완성도 뿐만 아니라 이후의 확장이나 유지, 보수를 위해서도 기초를 잘 다져 두어야 한다.

처음 시작이 중요한만큼 프로젝트를 맨바닥에서부터 만들어 보기로 한다. 이 강좌가 의도하는 바는 구현 기술뿐만 아니라 프로젝트를 시작하고 관리하는 것까지 포괄하므로 처음부터 실습을 따라해볼 필요가 있으며 직접 실습하는 과정을 가정하고 작성했다. 물론 진짜 다 해 볼 필요는 없고 다 그럴 것 같지도 않지만 제작 과정을 분명히 설명하기 위해서라도 따라하기식으로 진행한다.

먼저 실습 준비부터 하자. 실습 과정에서 생성할 수많은 예제를 한 디렉토리에 모을 필요가 있다. 각자 사정에 따라 임의의 디렉토리를 사용해도 무방하지만 여기서는 C:\SoEntyStudy 디렉토리에서 실습을 진행하기로 한다. 컴파일러는 비주얼 스튜디오 2019 영문 버전을 사용한다. 최근 마이크로소프트는 C#에 신경쓰느라 Win32는 홀대하고 있는데 더구나 국제화에는 더 무신경해 한글 버전에서는 버그가 많다.

MS 공식 사이트에서 비주얼 스튜디오를 검색해 설치하면 기본적으로 한글 버전을 설치해 주는데 설치 옵션에서 영문도 같이 선택하면 된다. 설사 한글만 선택했더라도 차후에 영문 언어팩을 추가로 받아 설치할 수도 있다. 꼭 한글 버전을 사용하겠다면 상관은 없지만 리소스 편집기에 버그가 있어 귀찮아진다. 이 두가지만 준비하면 바로 실습을 따라할 수 있다.

비주얼 스튜디오 2019를 실행하고 프로젝트부터 생성한다. File/New/Project 항목 선택 후 Windows Desktop Wizard 템플릿을 선택한다. Windows Deskop Application 템플릿은 질문없이 지맘대로 프로젝트를 생성해 버리므로 적합하지 않으며 반드시 마법사로 시작해야 한다.

프로젝트 이름은 SoEnty로 입력하고 위치는 미리 준비해둔 실습 디렉토리로 지정한다. 아래쪽의 체크 박스를 클릭하여 솔루션과 디렉토리를 같은 폴더에 생성한다. 그렇지 않으면 디렉토리 구조가 복잡해져 실습이 불편해진다. Create 버튼을 클릭하면 프로젝트의 형식을 묻는 대화상자가 나타난다. 디폴트는 콘솔로 되어 있는데 Destktop Application(.exe)를 선택하고 Empty project 옵션만 선택한다.

마법사를 사용하면 리소스도 생성해 주고 pch 설정까지 다 해 주어 편리하지만 소스가 장황하고 불필요한 기능까지 마구 집어 넣어 버린다. 게다가 마법사가 만들어주는 리소스에는 버그까지 있다. 아예 빈 프로젝트로 시작한 후 필요한 요소를 하나씩 추가해 나가는게 속편하다.

OK 버튼을 누르면 프로젝트만 덩그러니 생성되며 골조만 만들어진다. 빈 프로젝트에 필요한 소스 파일을 하나씩 추가하여 기능을 확장해 보자. 제일 처음 추가할 모듈은 공통 함수 기능을 제공하는 유틸리티이다. 솔루션 탐색기의 Header Files 노드에서 팝업 메뉴를 불러낸 후 Add/New Item 항목을 선택한다.

새 항목 대화상자가 나타나는데 Header File(.h)를 선택하고 파일명은 Util.h로 입력한다. 이후에도 파일 추가시 Header 하나 Source 하나씩 각각 추가하면 된다.

새로 만들어진 파일에 #pragma once 구문이 미리 작성되어 있는데 헤더 파일 중복 포함을 방지한다. 그러나 미리 컴파일된 헤더 기능을 쓰면 굳이 필요 없다. 지워 버리고 몇 가지 매크로와 함수의 원형을 작성한다. 직접 타이프 쳐 넣기는 번거로우므로 배포 소스에서 복사해 붙여 넣되 파일을 반드시 하나씩 직접 만들어 보고 코드도 대충 훓어 보자.

// 매크로 함수

#define Count(a) (sizeof(a)/sizeof(a[0]))

#define TextOutSz(h,x,y,t) TextOut(h,x,y,t,lstrlen(t));

#define ABS(a) ((a) >= 0 ? (a):-(a))

#define random(n) (rand()%(n))

// 유틸리티 함수 원형

void Trace(LPCTSTR format, ...);

void WriteLog(LPCTSTR strLog, ...);

void DrawBitmap(HDC hdc, int x, int y, HBITMAP hBit);

일반적으로 많이 사용하는 매크로 함수 몇 개 선언했다. 디버깅 확인을 위한 Trace, WriteLog 함수와 비트맵을 출력을 위한 DrawBitmap 함수 두 개만 일단 포함시켰는데 이후 계속 늘어날 것이다. 프로젝트의 다른 부분에서 종종 참고하는 전역 함수를 Util 모듈에 작성해 두면 편리하다.

두 함수의 구현 코드는 Util.cpp에 작성한다. 솔루션 탐색기의 Source Files 노드에서 팝업 메뉴를 열고 Add/New Items 항목을 선택한 후 파일명을 Util.cpp로 입력한다.

새 편집창이 열리는데 여기에 다음 코드를 작성한다. C++ 코딩 규칙에 맞게 원형은 헤더 파일에, 코드는 구현 파일에 작성한다. C 개발자에게는 익숙한 일반적인 방법이지만 선언과 정의과 분리되어 있지 않은 C#이나 자바에 비해서는 다소 불편한 방법이다.

#include <windows.h>

#include <tchar.h>

#include "Util.h"

#ifdef _DEBUG

void Trace(LPCTSTR format, ...)

{

TCHAR buf[1024];

va_list marker;

va_start(marker, format);

_vstprintf_s(buf, Count(buf), format, marker);

lstrcat(buf, L"\r\n");

OutputDebugString(buf);

}

void WriteLog(LPCTSTR strLog, ...)

{

static int count = 0;

static LPCTSTR LogPath = TEXT("c:\\Temp\\SoEnty_Debug.txt");

HANDLE hLog;

DWORD dwWritten;

TCHAR szLog[1024];

TCHAR strLog2[1024];

va_list marker;

SYSTEMTIME st;

va_start(marker, strLog);

_vstprintf_s(szLog, Count(szLog), strLog, marker);

if (count == 0) {

hLog = CreateFile(LogPath, GENERIC_WRITE, 0, NULL,

CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

} else {

hLog = CreateFile(LogPath, GENERIC_WRITE, 0, NULL,

OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

}

GetLocalTime(&st);

_stprintf_s(strLog2, Count(strLog2), TEXT("카운터=%06d(%d:%d:%d:%d) %s\r\n"), count++,

st.wHour, st.wMinute, st.wSecond, st.wMilliseconds, szLog);

SetFilePointer(hLog, 0, NULL, FILE_END);

WriteFile(hLog, strLog2, lstrlen(strLog2), &dwWritten, NULL);

CloseHandle(hLog);

}

#else

void Trace(LPCTSTR format, ...) { ; }

void WriteLog(LPCTSTR strLog, ...) { ; }

#endif

void DrawBitmap(HDC hdc, int x, int y, HBITMAP hBit)

{

HDC MemDC;

HBITMAP oldBitmap;

int bx, by;

BITMAP bit;

MemDC = CreateCompatibleDC(hdc);

oldBitmap = (HBITMAP)SelectObject(MemDC, hBit);

GetObject(hBit, sizeof(BITMAP), &bit);

bx = bit.bmWidth;

by = bit.bmHeight;

BitBlt(hdc, x, y, bx, by, MemDC, 0, 0, SRCCOPY);

SelectObject(MemDC, oldBitmap);

DeleteDC(MemDC);

}

Trace는 디버깅 문자열을 콘솔로 출력하여 프로그램을 멈추지 않고도 동작 상태를 관찰하는 도우미 함수이다. printf 처럼 서식 조립을 지원하여 한줄로 변수값이나 프로그램의 상태를 출력해 볼 수 있어 편리하다. 서식 조립을 위해 _vstprintf_s 함수를 사용하는데 버퍼 길이를 인수로 전달하여 안정성이 높다. 예전에는 다음 함수를 사용했었다.

_vstprintf(buf, format, marker);

사실, 이 함수도 원래의 C 함수는 아니고 원본은 sprintf이되 유니코드까지 지원하는 매크로 함수이다. 이 함수만 해도 그럭 저럭 쓸만 하지만 버퍼 길이를 지정할 수 없으며 버퍼가 항상 넉넉하다고 가정하고 문자열을 조립하기 때문에 위험한 면이 있다.

C++은 안정성을 점점 확보하는 방향으로 발전하고 있어 이런 위험한 함수는 에러로 처리한다. 그러나 과거와의 호환성을 위해 완전히 금지할 수는 없어 SDL checks 옵션을 끄면 여전히 사용할 수 있다. 앞으로는 쓰지 말라는 뜻으로 프로젝트 생성시 디폴트로 SDL 옵션이 켜져 있다.

안전함을 위해 구형 함수를 사용하지 말라는 뜻은 이해하겠지만 어떤 경우는 컴파일러의 잔소리가 너무 심한 편이다. 멀쩡히 잘 되던 코드까지도 에러로 처리해 버리는 과격함 때문에 기존 개발자가 적응하기 어렵다. 이 함수 아니라도 lstrcpy, wsprintf 등 아직도 위험한 함수는 얼마든지 있으며 여전히 사용 가능하다.

위험함을 감수하고라도 이런 함수가 아직 남아 있는 근본적인 이유는 C는 원래부터 배열 끝을 점검하지 않기 때문이며 그 후계자인 C++도 마찬가지 한계를 가지고 있다. 지금까지 이런 특성이 큰 문제가 되지 않았던 것은 C 개발자는 항상 버퍼를 넉넉히 준비하고 정 필요하면 사전에 버퍼 길이를 점검하는 식으로 대비했기 때문이다.

이런 특성의 반대 급부로 결과 프로그램이 작고 빠르며 그 특성으로 인해 C/C++이 여태까지 살아 남았으며 고유의 활용 영역이 있는 것이다. 활용 분야가 다르니 중급 언어가 성능을 포기해 가며 고급 언어를 따라 가는 것은 바람직하지 않다는 것이 개인적인 생각이다. 쓰기 쉽고 안전한 언어는 얼마든지 많고 C는 그 나름대로의 역할이 있으니 C는 C다워야 한다.

그러나 이건 나의 개인적인 취향일 뿐이며 요즘의 전반적인 흐름은 원론적인 안정성을 확보하자는 쪽이다. 이 강좌는 표준의 이런 취지에 맞게 가급적이면 권장되는 방식으로 예제 코드를 작성하되 너무 심하다 싶은 부분은 경고를 무시하기로 한다. 나중에 따로 살펴 보겠지만 비주얼 스튜디오의 경고는 너무 과한 면이 있다.

WriteLog 함수는 로그 기록을 파일로 남긴다. 멀티 스레드 디버깅은 로그를 남긴 후 살펴 보는 것이 효율적이다. 이 프로젝트에서는 당장은 사용하지 않지만 장래를 위해 미리 포함시켜 두었다. 디버깅 함수는 디버깅 버전에서만 본체를 정의한다. 릴리즈 버전에서는 괜히 실행 시간을 까먹을 필요가 없다.

CWindow

SoEnty 프로젝트는 C++ 언어와 Win32 API를 사용하여 개발한다. 이 조합으로 운영체제의 모든 기능을 자유롭게 사용할 수 있고 작고 빠른 프로그램을 만들 수 있다. 그러나 저수준 개발 방법이다 보니 편의성이 떨어지고 생산성도 낮아 시간도 많이 걸린다. 이 조합의 단점은 다음과 같다.

- 윈도우 하나를 생성하려면 윈도우 클래스를 정의하고 윈도우 프로시저와 각 메시지의 핸들러까지 만들어야 하니 과정이 길고 번잡하다.

- 메시지를 직접 받아 wParam, lParam을 해석하여 의미를 파악하고 반응을 보여 한다. 매번 레퍼런스를 참고해야 하며 캐스팅도 자주 해 실수할 가능성이 많다.

- 각 함수로 전달할 인수가 너무 구체적이고 시시콜콜한 것까지 다 밝혀야 한다. 기반 언어가 C이다 보니 인수가 많고 인수의 의미까지도 복잡해 직관적으로 외우기 어렵다.

- 작업 후 정리가 모두 수동이어서 일일이 신경써야 하며 하나라도 빼 먹으면 리소스가 누출되는 위험이 있다.

이런 불편함 때문에 Win32를 바로 쓰는 경우는 별로 없고 더 고수준의 언어로 래핑해서 사용한다. 대표적인 예가 MFC이다. 모든 것을 객체화하고 생성자, 파괴자를 통해 자동화해 두어 단 몇 줄만의 코드로도 원하는 것을 할 수 있다. 개발툴의 지원도 풍부해 리소스 편집이나 핸들러 연결이 쉽다. 그러나 MFC 또한 단점이 만만치 않다.

- 런타임이 너무 거대해 배포가 어렵고 단독 실행 파일하지 못한다. 게다가 MFC도 여러 버전이 있어 런타임 버전을 잘 맞추어야 하는 부담이 있다.

- 코드를 축약하기 위한 매크로가 복잡하고 중첩이 심해 비직관적이다. 매크로 헬에 빠지면 헤어 나오기 어렵고 예상치 못한 문제에 봉착한다. 한번 익숙해지면 쓰기 편하지만 제대로 익숙해지기 참 어렵다.

- 추상화 수준이 충분하지 않으며 Win32를 단순히 래핑해 놓은 것이어서 고급으로 올라갈 수록 예상치 못한 함정이 많다. 물론 해결 방법이 다 있지만 난이도가 높다.

MFC는 충분히 좋은 라이브러리이지만 유틸리티를 만들기에는 부담스러운 면이 있다. SoEnty는 MFC를 직접적으로 쓰지는 않지만 기본 개념을 빌려 와 객체화의 이점만 취하기로 한다. 다른건 Win32를 그대로 사용하더라도 윈도우만 객체로 만들어 두면 편의성이 엄청나게 증가한다.

참고로 윈도우를 객체화하는 상세한 문법에 대해서는 당근 텍스트 편집기 프로젝트에서 이미 다룬 바 있다. 당근 프로젝트 강좌의 다음 토픽을 참고하여 어떤 문제가 있고 어떻게 해결하는지 미리 예습을 해 두면 이 프로젝트를 이해하는데 많은 도움이 된다. SoEnty는 이 보다는 더 정교한 코드로 업그레이드하였다.

당근 1.0 강좌 9-1절, 9-2절

당근 1.2 강좌 21-1-다항, 21-1-사항

SoEnty 안에 윈도우를 객체와 맵핑하는 간이 기능을 작성해 넣을 것이다. MFC를 따라한 것인데 이름을 꼭 붙이자면 KFC 정도 된다. 이론은 복잡하지만 추상화 수준이 낮아 예상외로 코드양이 많지는 않다. 윈도우 객체와 객체맵은 CWindow 클래스로 구현한다. Window.h 헤더 파일을 생성하고 CWindow 클래스를 선언한다.

// 루트 윈도우 클래스. 윈도우 객체 관리도 담당한다.

class CWindow

{

public:

HWND win_hWnd; // 윈도우 핸들

COLORREF win_backColor; // 배경색

HBRUSH win_backBrush; // 배경 브러시

HBITMAP win_dblBuffer; // 더블버퍼링용 비트맵

CWindow();

~CWindow() { Dispose(); }

void Dispose();

// 평이한 차일드 윈도우로 생성하되 마지막 인수로 this를 전달하여 객체맵에 등록한다.

// 이 형태와 다른 윈도우(확장 스타일, 좌표 지정)는 Create를 재정의하여 직접 정의한다.

virtual void Create(HWND hParent, DWORD style = WS_CHILD | WS_VISIBLE,

int child_id = 0, LPCTSTR title = L"");

// 배경색상 지정 또는 변경

void SetBackColor(COLORREF color);

virtual LRESULT OnMessage(UINT iMessage, WPARAM wParam, LPARAM lParam);

virtual LRESULT OnCreate(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnDestroy(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnPaint(WPARAM wParam, LPARAM lParam);

virtual void OnDraw(HDC hdc, int width, int height) { }

virtual LRESULT OnTimer(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnSize(WPARAM wParam, LPARAM lParam);

virtual LRESULT OnCommand(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnContextMenu(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnKeyDown(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnLButtonDown(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnMouseMove(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnLButtonUp(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnLButtonDblClk(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnMouseWheel(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnUser1(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnUser2(WPARAM wParam, LPARAM lParam) { return 0; }

virtual LRESULT OnDropFiles(WPARAM wParam, LPARAM lParam) { return 0; }

// 객체 맵

static map<HWND, CWindow*>* pWinMap;

static void DeleteMap();

static LRESULT CALLBACK CWindowProc(HWND hWnd, UINT iMessage, WPARAM wParam, LPARAM lParam);

};

CWindow는 일반적인 윈도우 하나를 표현하는 클래스이다. 윈도우 핸들은 당연히 가져야 하며 더블버퍼링 기능을 기본적으로 제공한다. 대부분의 컨트롤이 깜박임 감소를 위해 더블버퍼링을 구현하므로 아예 루트 윈도우 자체에 이 기능을 넣었다. 이를 위해 배경색과 배경 브러시가 필요해 멤버로 포함한다.

CWindow의 멤버는 모두 win_ 접두로 시작하여 윈도우 소속임을 분명히 했다. 명칭을 분명히 밝히지 않으면 지역 변수와 헷갈려 엉뚱한 실수를 할 위험이 높다. 이럴 때 보통 m_ 접두를 붙이는데 KFC는 아예 소속 클래스명을 접두로 붙여 정의된 위치를 분명히 밝히도록 했다.

생성자, 파괴자가 정의되어 있되 파괴자를 외부에서 직접 호출할 수 있도록 Dispose 메서드로 분리해 두었다. 윈도우를 생성하는 Create와 배경색을 지정 또는 변경하는 SetBackColor를 정의했다. 메시지 핸들러는 모두 가상으로 선언해 두어 파생 클래스에서 언제든지 재정의할 수 있도록 해 두었다.

CWindow는 윈도우이면서 윈도우를 관리하는 객체 맵도 포함한다. 스스로 관리 객체를 내부에 두는 것이 좀 어색하지만 정적 멤버로 두면 별도의 상위 클래스가 필요 없어 형태가 단순해지는 이점이 있다. pWinMap은 윈도우 핸들과 윈도우 객체의 쌍을 저장하는 맵이다. 이 맵을 통해 윈도우 핸들로부터 객체를 찾아 적절한 메시지 핸들러를 호출한다.

정적 멤버 함수인 CWindowProc은 모든 윈도우의 메시지를 먼저 받는 메시지 프로시저이다. 객체 맵을 통해 어디로 전달할 메시지인지 판별하여 메시지를 분배하는 역할을 하며 새로 생성된 윈도우를 맵에 등록하기도 한다. 구현 파일까지 작성한 후 분석해 보자. Window.cpp 파일을 추가하고 다음 코드를 작성한다.

#include <windows.h>

#include <map>

using namespace std;

#include "Window.h"

#include "Util.h"

extern HINSTANCE g_hInst;

// 객체 맵 정적 멤버 선언

map<HWND, CWindow*> * CWindow::pWinMap;

CWindow::CWindow() {

Trace(L"CWindow 생성자 호출");

SetBackColor(RGB(255, 255, 255));

win_dblBuffer = nullptr;

// 최초 한번만 윈도우 클래스를 등록하고 객체 맵을 초기화한다.

if (pWinMap == nullptr) {

Trace(L"윈도우 클래스 등록, 윈도우 맵 초기화");

pWinMap = new map<HWND, CWindow*>();

WNDCLASS WndClass;

WndClass.cbClsExtra = 0;

WndClass.cbWndExtra = 0;

// 더블버퍼링이 기본 제공되어 배경 브러시는 없다.

WndClass.hbrBackground = NULL;

WndClass.hCursor = LoadCursor(NULL, IDC_ARROW);

WndClass.hIcon = LoadIcon(NULL, IDI_APPLICATION);

WndClass.hInstance = GetModuleHandle(NULL);

// 윈도우 프로시저와 윈도우 클래스명이 고정되어 있다.

WndClass.lpfnWndProc = (WNDPROC)CWindow::CWindowProc;

WndClass.lpszClassName = L"CWindow";

WndClass.lpszMenuName = NULL;

// 더블클릭을 기본 지원한다.

WndClass.style = CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS;

RegisterClass(&WndClass);

}

void CWindow::Dispose() {

Trace(L"CWindow Dispose 호출");

if (win_backBrush != nullptr) DeleteObject(win_backBrush);

if (win_dblBuffer != nullptr) DeleteObject(win_dblBuffer);

// 맵에서 윈도우 제거. 맵 자체가 이미 파괴되었으면(프로그램 종료시) 정리할 필요 없다.

if (pWinMap != nullptr) {

pWinMap->erase(win_hWnd);

Trace(L"%x 윈도우 제거", win_hWnd);

}

void CWindow::Create(HWND hParent, DWORD style, int child_id, LPCTSTR title) {

CreateWindow(TEXT("CWindow"), title, style,

0, 0, 0, 0, hParent, (HMENU)(ULONG_PTR)child_id, g_hInst, this);

}

void CWindow::SetBackColor(COLORREF color) {

win_backColor = color;

if (win_backBrush != nullptr) DeleteObject(win_backBrush);

win_backBrush = CreateSolidBrush(color);

}

void CWindow::DeleteMap() {

delete pWinMap;

pWinMap = nullptr;

}

// 기본 메시지를 처리해 주며 차일드는 메시지 핸들러로 받는다. 그 외의 메시지는 차일드가 직접 처리해야 한다.

LRESULT CWindow::OnMessage(UINT iMessage, WPARAM wParam, LPARAM lParam) {

switch (iMessage)

{

case WM_CREATE:

return OnCreate(wParam, lParam);

case WM_DESTROY:

return OnDestroy(wParam, lParam);

case WM_SIZE:

return OnSize(wParam, lParam);

case WM_PAINT:

return OnPaint(wParam, lParam);

case WM_TIMER:

return OnTimer(wParam, lParam);

case WM_COMMAND:

return OnCommand(wParam, lParam);

case WM_CONTEXTMENU:

return OnContextMenu(wParam, lParam);

case WM_KEYDOWN:

return OnKeyDown(wParam, lParam);

case WM_LBUTTONDOWN:

return OnLButtonDown(wParam, lParam);

case WM_MOUSEMOVE:

return OnMouseMove(wParam, lParam);

case WM_LBUTTONUP:

return OnLButtonUp(wParam, lParam);

case WM_LBUTTONDBLCLK:

return OnLButtonDblClk(wParam, lParam);

case WM_MOUSEWHEEL:

return OnMouseWheel(wParam, lParam);

case WM_USER + 1:

return OnUser1(wParam, lParam);

case WM_USER + 2:

return OnUser2(wParam, lParam);

case WM_DROPFILES:

return OnDropFiles(wParam, lParam);

}

return(DefWindowProc(win_hWnd, iMessage, wParam, lParam));

}

// OnPaint는 일단 루트가 받은 후 더블버퍼링 준비를 해서 OnDraw 가상 함수를 호출한다.

// 더블버퍼링을 원하지 않을 경우 직접 재정의한다.

LRESULT CWindow::OnPaint(WPARAM wParam, LPARAM lParam)

{

HDC hdc;

PAINTSTRUCT ps;

HDC hMemDC;

HBITMAP oldBit;

RECT crt;

GetClientRect(win_hWnd, &crt);

hdc = BeginPaint(win_hWnd, &ps);

if (win_dblBuffer == nullptr) {

win_dblBuffer = CreateCompatibleBitmap(hdc, crt.right, crt.bottom);

}

hMemDC = CreateCompatibleDC(hdc);

oldBit = (HBITMAP)SelectObject(hMemDC, win_dblBuffer);

FillRect(hMemDC, &crt, win_backBrush);

// 차일드에게 메모리 DC를 생성하여 전달한다.

OnDraw(hMemDC, crt.right, crt.bottom);

SelectObject(hMemDC, oldBit);

DeleteDC(hMemDC);

DrawBitmap(hdc, 0, 0, win_dblBuffer);

EndPaint(win_hWnd, &ps);

return 0;

}

// 크기가 바뀌면 더블버퍼링 비트맵을 새로 만든다.

// 파생 클래스는 WM_SIZE를 받았을 때 CWindow::OnSize부터 먼저 호출해야 한다.

LRESULT CWindow::OnSize(WPARAM wParam, LPARAM lParam)

{

if (win_dblBuffer != nullptr) {

DeleteObject(win_dblBuffer);

win_dblBuffer = nullptr;

}

return 0;

}

// 모든 윈도우의 메시지 프로시저는 이 함수 하나 뿐이다.

LRESULT CALLBACK CWindow::CWindowProc(HWND hWnd, UINT iMessage, WPARAM wParam, LPARAM lParam)

{

CWindow* pWin = nullptr;

// 맵에 등록되어 있는 윈도우인지 찾는다.

if (pWinMap->find(hWnd) != pWinMap->end()) {

pWin = (*pWinMap)[hWnd];

}

// 없으면 맵에 추가한다.

if (pWin == nullptr) {

// WS_THICKFRAME 스타일이 있을 때 가장 먼저 오며 이때 lParam은 MINMAXINFO여서 객체를 찾을 수 없다.

if (iMessage == WM_GETMINMAXINFO) {

return DefWindowProc(hWnd, iMessage, wParam, lParam);

}

pWin = (CWindow*)((LPCREATESTRUCT)lParam)->lpCreateParams;

// 객체 추가하고 객체의 멤버에 윈도우 핸들 대입

(*pWinMap)[hWnd] = pWin;

pWin->win_hWnd = hWnd;

Trace(L"새 윈도우 추가. 객체 : %x - 윈도우 %x", pWin, hWnd);

}

// 윈도우 객체로 메시지를 전달한다.

return pWin->OnMessage(iMessage, wParam, lParam);

}

생성자는 배경색을 흰색으로 초기화하고 더블버퍼링 비트맵도 nullptr로 초기화한다. 비트맵은 처음 WM_PAINT 메시지를 받았을 때 작업영역 크기에 맞게 생성하며 배경색은 원할 경우 언제든지 다른 색으로 변경할 수 있다.

이후의 모든 윈도우를 생성하기 위한 윈도우 클래스를 등록하되 이 작업은 pWinMap이 아직 생성되지 않은 최초 딱 한번만 수행한다. 원래는 WinMain에서 해야 하는 작업이나 클라이언트의 부담을 줄이기 위해 어떤 윈도우든지 처음 생성되는 윈도우가 등록하도록 했다.

CWindow가 등록하는 윈도우 클래스의 메시지 프로시저는 CWindowProc으로 고정되어 있으며 윈도우 클래스명도 고정이다. 즉, 모든 윈도우는 운영체제 입장에서는 똑같은 윈도우이되 객체가 메시지 처리 함수를 어떻게 정의하는가에 따라 동작이 달라진다. 행동 방식이 윈도우 클래스가 아닌 C++ class에 의해 결정된다.

윈도우 클래스를 등록할 때 객체 맵도 생성한다. pWinMap 정적 변수는 최초 nullptr이다가 첫 생성자 호출시 생성한다. pWinMap이 생성되면 이후부터 생성되는 윈도우는 자신만 초기화할 뿐 윈도우 클래스나 객체 맵은 신경쓰지 않는다. 초기화 전과 후를 구분하기 위해 맵을 정적 변수가 아닌 포인터로 선언했다.

Dispose 메서드는 파괴자가 호출하는 정리 함수이다. 코드에서 파괴자를 직접 호출할 수 없기 때문에 별도의 메서드로 빼 두었다. 브러시와 더블버퍼링 비트맵을 파괴하는 것은 기본 정리 절차이며 객체 맵에서도 윈도우를 제거하되 이 조건은 좀 복잡하다. 이후 메인 윈도우까지 만든 후 다시 연구해 보자.

Create는 윈도우를 생성한다. 객체를 생성하는 것과 윈도우를 생성하는 것은 다르다. 객체는 어디까지나 메모리 내의 정보 집합일 뿐이며 화면상에 움직이는 실체가 아니다. CreateWindow를 호출해야 화면에 표시하는 윈도우가 된다. 윈도우 클래스는 고정되어 있고 스타일, ID, 제목은 인수로 지저할 수 있다.

OnMessage는 메시지와 가상 함수를 연결한다. 대부분의 윈도우가 기본적으로 처리하는 메시지를 모두 등록해 두었으며 사용자 정의 메시지에 대한 핸들러도 2개나 등록해 두었다. 미리 연결해 놓지 않은 나머지 메시지는 모두 DefWindowProc으로 전달하여 디폴트 처리한다. OnMessage를 통해 각 윈도우는 자신이 정의한 가상 함수로 메시지를 받게 된다.

이것이 가능하도록 하기 위해 객체 맵을 관리하고 핸들로부터 객체를 찾아 가상 함수를 호출하도록 체계를 만들어 가는 것이다. 각 메시지를 어떻게 처리할 것인가는 개별 윈도우가 마음대로 결정할 수 있도록 CWindow의 기본 구현은 모두 0을 리턴하는 것으로 되어 있다. 단, OnPaint와 OnSize에 대해서는 기본 구현을 제공한다.

OnPaint는 작업영역 크기에 맞게 더블버퍼링 비트맵을 생성하고 이 비트맵을 DC에 선택해 둔다. 배경 브러시로 비트맵을 모두 채운 후 OnDraw로 DC와 작업영역 크기를 전달한다. 객체가 배경을 채우므로 윈도우 클래스의 배경 브러시는 NULL이다. 결국 윈도우에 무엇을 그릴 것인가는 파생 클래스의 OnDraw에서 어떻게 출력하는가에 따라 결정된다. OnDraw가 비트맵을 완성하여 리턴하면 이 비트맵을 화면으로 고속 전송한다.

OnSize는 윈도우 크기가 바뀔 때 더블버퍼링 비트맵을 무효화한다. 비트맵을 지워 놓기만 하면 OnPaint에서 변경된 작업영역 크기에 맞추어 새로 생성하도록 되어 있다. 두 핸들러가 더블버퍼링을 잘 지원하고 있으므로 차일드는 OnDraw에서 허가된 영역에 그리고 싶은 것만 그리면 된다.

대부분의 윈도우는 깜박임 방지를 위해 더블버퍼링이 필요하다. 더블버퍼링을 하지 않거나 불필요하다면 OnPaint를 재정의하여 직접 그리면 된다. 이 경우는 OnSize의 코드도 딱히 필요치 않지만 비트맵이 항상 nullptr이므로 그대로 두어도 별다른 부작용은 없다.

CWindowProc은 CWindow 파생 클래스의 메시지를 받는 윈도우 프로시저이다. 운영체제가 요구하는 원형에 맞추기 위해 정적 메서드로 선언했다. 운영체제는 윈도우 핸들에 대해 메시지를 보내는데 우리는 윈도우를 객체로 정의했다. 따라서 핸들과 객체를 대응시킬 필요가 있는데 이 정보를 arWinMap이 가지며 핸들과 객체의 변환을 CWindowProc이 처리한다.

CWindowProc의 주업무는 윈도우 핸들과 객체의 대응표를 보고 객체를 찾아 가상 함수를 호출하는 것이다. 이 외에도 새로 들어온 메시지의 주인이 아직 등록되어 있지 않으면 객체 맵에 등록하여 이후부터 객체를 통해 메시지를 받을 수 있도록 조치한다.

윈도우 운영체제는 객제 지향적이지 않지만 CWindowProc에 의해 윈도우는 객체가 되고 가상 함수에 의해 다형적으로 동작한다. 이 체계를 잘 구축해 놓으면 이후부터 윈도우를 생성하고 동작을 정의하기 편리하며 C++의 모든 이점을 누릴 수 있다.

메인 모듈

여기까지는 윈도우를 생성하고 운용할 준비만 했다. 이제 실제 윈도우를 만들어 보자. SoEnty.h 헤더 파일을 추가하고 메인 윈도우와 간단한 시계 윈도우를 선언한다. 관행상 클래스 이름은 모두 대문자 C로 시작한다.

// 메인 윈도우 클래스 선언

class CMainWindow : public CWindow

{

public:

// CWindow의 Create와 다를 경우 별도의 함수를 만든다.

// 대부분의 차일드는 재정의 불필요하다.

void Create();

// 관심있는 메시지의 핸들러만 재정의한다.

LRESULT OnMessage(UINT iMessage, WPARAM wParam, LPARAM lParam);

LRESULT OnCreate(WPARAM wParam, LPARAM lParam);

LRESULT OnDestroy(WPARAM wParam, LPARAM lParam);

LRESULT OnKeyDown(WPARAM wParam, LPARAM lParam);

};

class CClock : public CWindow

{

public:

// 필요한 멤버를 정의한다.

TCHAR sTime[128];

LRESULT OnCreate(WPARAM wParam, LPARAM lParam);

LRESULT OnDestroy(WPARAM wParam, LPARAM lParam);

LRESULT OnTimer(WPARAM wParam, LPARAM lParam);

void OnDraw(HDC hdc,int width, int height);

};

둘 다 CWindow로부터 파생되며 기본 속성과 동작을 물려 받은 후 원하는 기능만 재정의하면 된다. 모든 파생 클래스는 배경색을 가지고 더블버퍼링을 지원하며 OnMessage를 통해 메시지를 분배하는 능력을 가진다. 대개의 경우 메시지 핸들러만 재정의해도 원하는 기능을 작성할 수 있다. 클래스 선언문에 재정의할 메서드 목록을 나열한다.

메인 윈도우는 대장이라는 점에서 속성과 메시지 처리가 특이해 Create와 OnMessage를 재정의한다. 사실 Create 함수는 원형이 달라 재정의가 아니라 아예 다른 함수를 하나 더 만든 것이다. 메인 윈도우이니만큼 차일드와는 생성 방법이 독특하다.

CClock은 메시지 핸들러 외에 현재 시간을 저장할 sTime 버퍼를 멤버로 선언한다. 클래스이므로 당연히 멤버를 자유롭게 추가할 수 있다. 필요한 모든 것을 클래스 내부에 캡슐화하여 다른 클래스와 명칭 충돌을 걱정할 필요가 없다. 프로젝트가 아무리 커져도 클래스 안에서 멤버를 자유롭게 선언할 수 있다.

CWindow는 물론이고 CMainWindow, CClock의 모든 멤버는 다 public이며 모두 공개되어 있다. 객체는 내부 구현을 적절히 숨겨야 하지만 이 프로젝트의 객체는 작성자가 곧 사용자이므로 굳이 그럴 필요 없다. 개발중에 모든 멤버는 공개이되 나중에 꼭 필요한 멤버만 선별적으로 숨기면 된다. 구현 파일은 SoEnty.cpp 파일에 작성한다.

#include <windows.h>

#include <tchar.h>

#include <map>

using namespace std;

#include "Window.h"

#include "SoEnty.h"

#include "Util.h"

// 인스턴스 핸들 객체

HINSTANCE g_hInst;

// 메인 윈도우

CMainWindow mainWindow;

// mainWindow 안에 포함시켜도 상관 없음.

CClock childClock;

CClock* pClock;

void CMainWindow::Create()

{

// 윈도우 클래스는 무조건 CWindow로 지정한다. 메인은 CHILD가 아니어서 재정의했다.

CreateWindow(L"CWindow", L"main", WS_OVERLAPPEDWINDOW,

10, 10, 640, 480, nullptr, (HMENU)0, g_hInst, this);

}

LRESULT CMainWindow::OnMessage(UINT iMessage, WPARAM wParam, LPARAM lParam) {

// 핸들러가 정의되지 않은 메시지를 직접 처리한다.

switch (iMessage)

{

case WM_RBUTTONDOWN:

MessageBox(win_hWnd, L"마우스 오른쪽 버튼을 눌렀습니다.", L"알림", MB_OK);

return 0;

}

// 핸들러가 정의되어 있는 메시지는 핸들러를 찾아 호출한다.

return CWindow::OnMessage(iMessage, wParam, lParam);

}

LRESULT CMainWindow::OnCreate(WPARAM wParam, LPARAM lParam)

{

Trace(L"MainWindow OnCreate. hWnd = %x", win_hWnd);

childClock.Create(win_hWnd);

MoveWindow(childClock.win_hWnd, 10, 10, 300, 100, TRUE);

childClock.SetBackColor(RGB(255, 255, 0));

return 0;

}

LRESULT CMainWindow::OnDestroy(WPARAM wParam, LPARAM lParam)

{

PostQuitMessage(0);

return 0;

}

LRESULT CMainWindow::OnKeyDown(WPARAM wParam, LPARAM lParam)

{

switch (wParam) {

case '1':

// 차일드 윈도우를 다시 만든다.

if (IsWindow(childClock.win_hWnd) == FALSE) {

childClock.Create(win_hWnd);

MoveWindow(childClock.win_hWnd, 10, 10, 300, 100, TRUE);

childClock.SetBackColor(RGB(255, 255, 0));

}

break;

case '2':

if (IsWindow(childClock.win_hWnd)) {

// 실행중에 정적 차일드 윈도우를 파괴할 때의 처리.

DestroyWindow(childClock.win_hWnd);

// 여기서 객체를 제거한다. 파괴중의 메시지는 모두 SendMessage로 보내기 때문에 더 처리할 메시지가 없다.

childClock.Dispose();

// 정적으로 선언한 객체를 파괴할 필요는 없다.

}

break;

case '3':

// 실행중에 차일드 객체를 생성한다.

if (pClock == nullptr) {

pClock = new CClock();

pClock->Create(win_hWnd);

pClock->SetBackColor(RGB(0, 255, 0));

MoveWindow(pClock->win_hWnd, 10, 150, 300, 100, TRUE);

}

break;

case '4':

// 차일드 객체를 파괴한다.

if (pClock != nullptr) {

DestroyWindow(pClock->win_hWnd);

delete pClock;

pClock = nullptr;

}

break;

}

return 0;

}

LRESULT CClock::OnCreate(WPARAM wParam, LPARAM lParam)

{

Trace(L"Clock OnCreate. hWnd = %x", win_hWnd);

SetTimer(win_hWnd, 1, 1000, NULL);

SendMessage(win_hWnd, WM_TIMER, 1, NULL);

return 0;

}

LRESULT CClock::OnDestroy(WPARAM wParam, LPARAM lParam)

{

Trace(L"Clock OnDestroy. hWnd = %x", win_hWnd);

KillTimer(win_hWnd, 1);

return 0;

}

LRESULT CClock::OnTimer(WPARAM wParam, LPARAM lParam)

{

SYSTEMTIME st;

switch (wParam) {

case 1:

GetLocalTime(&st);

wsprintf(sTime, TEXT("지금 시간은 %d:%d:%d입니다"),

st.wHour, st.wMinute, st.wSecond);

InvalidateRect(win_hWnd, NULL, TRUE);

break;

}

return 0;

}

void CClock::OnDraw(HDC hdc, int width, int height)

{

SetTextAlign(hdc, TA_CENTER);

SetBkMode(hdc, TRANSPARENT);

TextOutSz(hdc, width / 2, 20, sTime);

}

// 메인 윈도우 생성하고 메시지 루프만 돌리면 된다.

int APIENTRY WinMain(_In_ HINSTANCE hInstance, _In_opt_ HINSTANCE hPrevInstance

, _In_ LPSTR lpszCmdParam, _In_ int nCmdShow)

{

MSG Message;

g_hInst = hInstance;

mainWindow.Create();

ShowWindow(mainWindow.win_hWnd, nCmdShow);

while (GetMessage(&Message, NULL, 0, 0)) {

TranslateMessage(&Message);

DispatchMessage(&Message);

}

// 종료 직전에 객체 맵을 해제한다.

CWindow::DeleteMap();

return (int)Message.wParam;

}

mainWindow와 childClock 객체가 전역으로 선언되어 있고 두 클래스의 멤버 함수가 정의되어 있다. 메인 윈도우는 차일드가 아닌 OVERLAPPEDWINDOW 속성을 가지며 생성할 때부터 캡션과 위치를 지정할 필요가 있어 Create 메서드를 재정의했다. CWindow의 Create 메서드도 캡션과 스타일은 지정할 수 있으므로 WinMain에서 다음과 같이 메인 윈도우를 생성해도 상관 없다.

mainWindow.Create(NULL, WS_OVERLAPPEDWINDOW, 0, L"main");

MoveWindow(mainWindow.win_hWnd, 10, 10, 640, 480, TRUE);

그러나 메인 윈도우는 그 특성상 이후에도 여러 가지 확장 스타일이 필요하고 위치나 크기를 저장 및 복구하는 처리도 필요해 Create를 미리 재정의해 두었다. 생성 메서드를 잘 정의해 두면 WinMain에서는 mainWindow.Create() 호출만으로 메인 윈도우를 쉽게 생성할 수 있다. 다음 두 문장을 잘 구분하자.

CMainWindow mainWindow; // 윈도우가 될 객체를 선언한다.

mainWindow.Create(); // 객체를 실제 윈도우로 생성한다.

CWindow 파생 클래스가 윈도우를 표현하지만 객체 자체가 윈도우는 아니다. 객체는 어디까지나 메모리에 생성된 멤버의 집합일 뿐이며 이 객체가 운영체제가 인정하는 윈도우가 되려면 결국 CreateWindow 함수를 호출해야 한다. 이 작업을 Create 메서드가 담당한다.

즉, 모든 윈도우 객체는 어느 시점이든간에 Create를 호출해야만 윈도우로 동작한다. 또한 Create는 윈도우 클래스를 항상 CWindow로 지정하여 CWindowProc으로 메시지를 보낸다. 이때 CreateWindow의 마지막 인수로 this를 전달하여 생성할 윈도우와 객체 자신의 관계를 형성하는 중요한 역할을 한다. 생성할 때 객체 맵에 등록해야 이후부터 OnMessage를 통해 메시지를 받을 수 있다.

OnMessage는 자주 사용하는 대부분의 메시지를 처리하며 윈도우의 모든 메시지를 다 처리하지는 않는다. 만약 CWindow가 핸들러를 제공하지 않는 메시지를 직접 처리하려면 OnMessage를 재정의하여 원하는 메시지를 처리하면 된다. 메인 윈도우는 WM_RBUTTONDOWN 메시지를 받았을 때 메시지 박스를 열며 이 메시지를 처리한 후 바로 리턴한다.

그 외의 메시지는 모두 CWindow::OnMessage로 보내 미리 정의한 가상 메시지 핸들러를 호출한다. 만약 CWindow가 정의한 메시지 외에 다른 메시지를 처리할 일이 없다면 OnMessage를 굳이 재정의할 필요는 없다. CClock이 그렇게 되어 있으며 대부분의 위젯은 CWindow의 핸들러만으로도 충분하다.

메인 윈도우의 OnCreate에서 childClock 윈도우를 생성한다. 차일드는 보통 부모의 OnCreate에서 생성한다. 위치를 적당히 잡고 배경색은 노란색으로 지정했다. OnDestroy는 윈도우 파괴시의 뒷정리를 하되 메인 윈도우는 PostQuitMessage를 호출하여 메시지 루프를 벗어나도록 해야 한다. OnKeyDown은 다음 항에서 연구해 볼 테스트 코드이다.

CClock 윈도우는 화면에 시계를 출력하고 주기적으로 갱신한다. OnCreate에서 1초 주기의 타이머를 설치하고 OnDestroy에서 타이머를 파괴한다. OnTimer에서 현재 시간을 조사하여 sTime 버퍼에 기록하며 OnDraw는 조사해 놓은 시간을 화면에 출력한다. 더블버퍼링 처리는 CWindow::OnPaint가 알아서 하고 있으므로 그리기만 하면 된다. 4개의 메시지를 처리하여 멋진 시계를 만들었다.

여기까지 메인 윈도우와 시계 윈도우를 정의했다. 이제 두 윈도우를 사용하여 프로그램을 만든다. 클래스가 대부분의 처리를 다 하고 있어 WinMain은 별로 할게 없다. 메인 윈도우를 생성하여 보이고 메시지 루프만 돌리면 그만이다. 프로그램 종료시 객체 맵을 해제하고 나간다.

여기까지의 과정은 길었지만 어차피 CWindow는 더 손델게 없다. 새로운 윈도우를 더 만들려면 CClock을 만들듯이 몇 줄의 선언문과 메시지 핸들러만 만들면 된다. 이래서 객체 지향이 좋은 것이며 일단 체계가 구축되면 생산성이 엄청나게 높은 것이다. 실행해 보자.

메인 윈도우와 노란 시계 윈도우가 잘 생성되며 훌륭하게 동작한다. 이 실습을 통해 객체 지향의 파워를 실감할 수 있다. 또한 내일 출근해야 하는데 새벽 4시까지 잠도 못자고 강좌를 쓰고 있음도 알 수 있다. 회사를 다니다 보면 어쩔 수 없는 일이다.

윈도우의 생성과 파괴

KFC를 이용한 첫번째 예제를 완성했으며 잘 실행되는 것도 확인해 보았다. 이제 윈도우가 생성 및 파괴되는 절차를 하나씩 탐구해 보자. 이 예제의 코드 한줄 한줄이 다 중요한 의미가 있어 각 코드의 역할을 분명히 이해해야 한다.

이 프로그램은 실행중에 어떤 사건이 일어나는지 살펴보기 위해 WM_KEYDOWN에 윈도우를 생성 및 파괴하는 테스트 코드를 작성해 두었다. 또한 윈도우 생명 주기마다 디버깅 메시지를 출력하여 내부 동작을 확인한다. 디버그 모드로 예제를 실행한 후 Output 창으로 출력되는 메시지를 보고 디버거로 단계 실행해 가며 어떤 흐름을 타는지 분석해 보자.

이 예제는 mainWindow와 childClock을 정적으로 선언한다. 정적 객체는 실행 직후에 바로 생성되는데 이때 다음 일련의 메시지가 출력된다. 각 메시지가 발생하는 이유에 대해 옆에 주석을 달아 두었다.

CWindow 생성자 호출 // mainWindow 객체 생성

윈도우 클래스 등록, 윈도우 맵 초기화 // 윈도우 맵 초기화

CWindow 생성자 호출 // childClock 객체 생성

두 변수가 생성되면서 생성자가 두 번 호출되었다. 처음 호출할 때 윈도우 클래스와 윈도우 맵을 초기화하고 두 번째 생성자 호출시에는 윈도우 맵이 이미 초기화되어 있어 재초기화하지 않는다. 여기까지는 변수만 생성했다. 다음은 WinMain으로 진입하여 mainWindow.Create()를 호출하며 여기서 CreateWindow로 메인 윈도우를 생성한다.

CreateWindow(L"CWindow", L"main", WS_OVERLAPPEDWINDOW,

10, 10, 640, 480, nullptr, (HMENU)0, g_hInst, this);

윈도우 클래스명이 CWindow로 고정되어 있음을 유의하자. 이후의 모든 윈도우는 소속이 같다. 그리고 마지막 인수 this가 중요한 역할을 한다. 윈도우를 생성할 때 파라미터로 윈도우 객체 자신의 포인터를 전달한다. 윈도우 생성중에 다음 두 메시가 출력되는데 이 흐름을 따라가 보자.

새 윈도우 추가. 객체 : b7854c - 윈도우 390620

MainWindow OnCreate. hWnd = 390620

윈도우를 생성했으니 생성 관련 메시지가 윈도우 프로시저로 전달된다. 모든 윈도우는 CWindowProc으로 메시지를 보낸다. 최초 pWinMap은 비어 있으며 아무 윈도우도 등록되어 있지 않다. 이때는 윈도우를 맵에 먼저 등록한다.

최초 전달되는 메시지는 WM_NCCREATE이며 이때 타이틀바, 경계선 등을 생성한다. 이 메시지의 lParam을 통해 파라미터가 전달되는데 CreateWindow 호출시 전달한 this, 즉 객체의 포인터를 구할 수 있다. 이 포인터와 핸들을 맵에 저장하여 이후부터는 맵에서 객체를 찾을 수 있도록 준비한다.

윈도우 스타일에 따라 메시지의 종류가 조금 달라지는데 WS_THICKFRAME 스타일이 있을 때는 크기를 결정하기 위해 WM_NCCREATE보다 WM_GETMINMAXINFO 메시지가 먼저 온다. 이 때는 this를 알 수 없으므로 이건 DefWindowProc으로 조용해 보내 줘야 한다. 일반 차일드는 항상 WM_NCCREATE가 먼저 오므로 this를 맵에 등록해 버리면 된다.

(*pWinMap)[hWnd] = pWin;

pWin->win_hWnd = hWnd;

맵에 윈도우를 등록하는 즉시 객체의 win_hWnd에 윈도우 핸들을 대입한다. 이후의 메시지 처리 루틴에서 객체는 win_hWnd를 통해 윈도우 핸들을 찾으므로 이 처리가 반드시 필요하다. 핸들로부터 객체를 찾을 때는 맵을 뒤지고 객체로부터 핸들을 찾을 때는 win_hWnd를 읽어 언제든지 서로를 찾을 수 있다.

다음으로 WM_NCCALCSIZE 메시지가 오는데 이때는 맵에 이미 윈도우가 등록되어 있으며 맵을 통해 윈도우 객체를 찾는다. 객체를 찾은 후 OnMessage 가상 함수를 호출하여 객체 스스로 메시지를 처리하도록 한다. 다음으로 WM_CREATE가 날라오며 이때도 맵을 통해 핸들러를 찾는다.

메인 윈도우의 OnCreate 핸들러가 호출되어 생성시 초기화를 처리한다. Create와 OnCreate를 헷갈리지 말자. Create는 윈도우를 만들라는 명령이고 OnCreate는 지금 만들고 있으니 필요한 초기화를 하는 곳이다. 메인 윈도우는 OnCreate에서 childClock을 생성한다. childClock은 Create를 재정의하지 않아 CWindow로부터 상속받은 Create를 호출한다.

CreateWindow(TEXT("CWindow"), title, style,

0, 0, 0, 0, hParent, (HMENU)(ULONG_PTR)child_id, g_hInst, this);

이때도 마지막 인수로 this가 전달됨을 유의하자. 생성시 객체 포인터를 전달해야 맵에 등록할 수 있고 이후의 메시지를 객체가 받을 수 있다. 이때 다음 두 메시지가 출력된다.

새 윈도우 추가. 객체 : b78438 - 윈도우 120976

Clock OnCreate. hWnd = 120976

childClock은 최초 WM_NCCREATE 메시지를 받으며 이때 맵에 자신을 등록한다. 연이어 전달되는 WM_NCCALCSIZE, WM_CREATE는 객체로 전달된다. CClock의 OnCreate에서 타이머를 등록하여 주기적으로 시간을 출력한다.

여기까지 진행하면 프로그램 초기화가 완료된 것이다. 이후 두 윈도우는 WM_SIZE, WM_MOVE, WM_TIMER 등의 메시지를 계속 받는다. 이때마다 CWindowProc으로 메시지가 전달되며 맵을 통해 메시지의 수신처를 알아내고 객체의 OnMessage를 거쳐 메시지 핸들러를 호출하며 실행된다.

윈도우를 생성하는 것만큼이나 파괴하는 절차도 중요하다. 파괴시 메시지를 제대로 처리해야 찌꺼기도 남지 않으며 마지막 정리 작업을 원활히 수행할 수 있다. OnKeyDown에 윈도우를 파괴하는 코드를 미리 작성해 두었는데 2번을 눌러 childClock을 파괴해 보자. 이때 다음 두 줄을 실행한다.

DestroyWindow(childClock.win_hWnd);

childClock.Dispose();

윈도우를 파괴할 때는 DestoryWindow를 호출한다. 이때 WM_DESTROY와 일련의 파괴 메시지가 전달되는데 OnDestroy에서 타이머를 해제한다. 윈도우 파괴중의 모든 메시지는 SendMessage로 보내지므로 DestroyWindow 리턴 후에는 모든 정리가 끝나고 더 처리할 메시지가 없다.

윈도우를 완전히 파괴한 후 Dispose 메서드를 호출하여 맵에서도 윈도우를 제거한다. 배경 브러시와 더블버퍼링 비트맵을 해제하고 맵에서 윈도우 핸들을 제거한다. 이 과정에서 출력되는 디버거 메시지는 다음과 같다. 윈도우 파괴, 정리, 맵 제거가 순조롭게 잘 처리됨을 알 수 있다.

Clock OnDestroy. hWnd = 120976

CWindow Dispose 호출

120976 윈도우 제거

윈도우 파괴시 이 모든 처리가 정상적으로 다 처리되어야 한다. OnDestroy가 오지 않으면 타이머나 차일드 제거, 실행 정보 저장 등이 처리되지 않으며 객체 맵에서 제거하지 않으면 불필요한 쓰레기가 남아 차후 어떤 부작용을 일으킬지 알 수 없다. 윈도우 파괴를 다음과 같이 해서는 안된다.

childClock.Dispose();

DestroyWindow(childClock.win_hWnd);

좀 있다 파괴할 윈도우라고 해서 Dispose를 먼저 호출해 버리면 파괴중의 메시지를 처리할 수 없어 다운된다. childClock은 정적으로 선언된 변수이므로 이 변수를 제거할 필요는 없다. 이 윈도우를 다시 재생성하면 최초 실행시와 똑같은 초기화 과정을 거친다. 키보드의 1키를 누르면 다시 생성하는데 정상적으로 잘 생성됨을 알 수 있다.

다음은 윈도우 객체를 동적으로 생성 및 파괴해 보자. 실행중에도 윈도우는 얼마든지 생성, 파괴 가능해야 한다. 이 처리를 위해 CClock * 타입의 pClock 변수를 선언해 두었으며 관련 코드는 OnKeyDown의 3번과 4번에 있다. 생성 코드부터 보자.

pClock = new CClock();

pClock->Create(win_hWnd);

pClock->SetBackColor(RGB(0, 255, 0));

MoveWindow(pClock->win_hWnd, 10, 150, 300, 100, TRUE);

new 연산자로 객체를 먼저 생성하고 Create 메서드를 호출하여 윈도우를 생성한다. 객체를 먼저 생성한 후 윈도우를 생성해야 한다. 그리고 배경색이나 위치 지정 등의 추가 작업을 처리한다. 이때 출력되는 메시지는 다음과 같다.

CWindow 생성자 호출

새 윈도우 추가. 객체 : e19088 - 윈도우 505ce

Clock OnCreate. hWnd = 505ce

객체 생성자가 호출되며 Create 호출시 WM_NCCREATE, WM_CREATE 메시지가 전달되는 과정에서 윈도우 맵에 등록하고 OnCreate에서 타이머를 생성하여 시간을 출력한다. 두 개의 차일드 윈도우가 아래, 위로 나란히 잘 실행된다.

이번에는 4키를 눌러 파괴해 보자. 동적으로 생성한 윈도우는 다 사용한 후 언제든지 파괴할 수 있어야 한다. 코드는 다음과 같다.

DestroyWindow(pClock->win_hWnd);

delete pClock;

pClock = nullptr;

파괴할 때는 윈도우 먼저 파괴하고 객체를 제거한다. 파괴중에도 메시지는 받아야 제대로 정리를 할 수 있으므로 그 동안에는 객체가 남아 있어야 한다. 동적으로 만든 객체이니 삭제할 때는 당연히 delete이며 이때 파괴자를 경유하여 Dispose를 호출하여 객체 맵에서 자신을 제거한다. 트레이스 메시지는 다음과 같다.

Clock OnDestroy. hWnd = 505ce

CWindow Dispose 호출

505ce 윈도우 제거

이 순서대로 호출되어 윈도우, 객체 순으로 파괴하고 맵에서도 제거한다. 생성할 때는 객체, 윈도우 순이고 파괴할 때는 반대로 윈도우, 객체 순이다. 객체가 윈도우를 래핑하므로 먼저 생성되어야 하고 완전히 파괴될 때까지 남아 있어야 한다.

C++은 생성자에서 초기화, 파괴자에서 정리를 자동으로 수행할 수 있는데 왜 생성, 파괴가 수동으로 되어 있을까? 사실 이렇게도 할 수 있으며 MFC는 과연 그렇게 되어 있다. 그러나 이렇게 만들자면 정적, 동적 생성 방법에 달라지며 클래스 계층상에서 삭제할 때의 예외 처리가 과하게 복잡하다. Dispose에서 윈도우를 파괴하는 코드를 넣어 보자.

void CWindow::Dispose() {

Trace(L"CWindow Dispose 호출");

if (win_backBrush != nullptr) DeleteObject(win_backBrush);

if (win_dblBuffer != nullptr) DeleteObject(win_dblBuffer);

if (IsWindow(win_hWnd)) { DestroyWindow(win_hWnd); }

....

객체 제거시 윈도우를 알아서 파괴하도록 해 두면 Dispose만 호출하면 된다. 그러나 이 코드는 윈도우가 계층을 이룰 때 문제가 있다. 상속받은 가상 파괴자는 다형적으로 동작하지 않아 파괴중의 WM_DESTROY를 처리할 OnMessage를 정확히 찾지 못한다. 이에 대한 문법적 이론에 대해서는 당근 1.2버전 강좌 21-1-사 항을 참고한다.

MFC는 별도의 내부 멤버 변수를 두어 이런 문제에도 잘 대처하지만 완벽한 자동도 아니어서 때로는 개발자가 내부 구조를 알아야 대처할 수 있는 경우도 있다. 과하게 자동화하려면 언젠가는 민감한 문제가 발생한다. KFC는 그 정도까지의 체계는 구축하지 않고 생성, 파괴할 때 순서만 잘 지키도록 했다. 약간의 불편 대신 단순함을 유지하자는 작전이다.

다음은 객체 맵 정리 코드를 보자. 맵 초기화하는 최초의 윈도우가 생성될 때 생성자에서 처리한다. 그러나 파괴는 클래스 수준에서 적당한 시점이 없다. 마지막 윈도우가 제거될 때 파괴자에서 처리할 수 있을 것 같지만 그 윈도우가 완전히 제거될때까지는 남아 있어야 하니 안된다. 그래서 맵 정리는 WinMain에서 메시지 루프 탈출 직후에 직접 한다.

delete pWinMap;

pWinMap = nullptr;

맵을 제거하고 nullptr로 만들어 불능화 시킨다. 맵이 없으면 더 이상 객체도 찾지 못하고 메시지를 처리하지도 못하지만 메시지 루프가 끝난 시점에 더 전달할 메시지도 없어 문제되지 않는다. 응용 프로그램이 종료되는 시점이라 사실 이 코드는 생략해도 메모리 누수는 없다.

Win32는 주소 공간이 분리되어 있어 프로그램이 종료되면 메모리는 모두 압수된다. 다만 기능적 완성도를 위해 깔끔하게 정리하고 나가는 것이다. 이 코드가 들어가면 Dispose에서 맵이 살아 있는지를 점검하는 조건문이 필요해진다.

if (pWinMap != nullptr) {

pWinMap->erase(win_hWnd);

Trace(L"%x 윈도우 제거", win_hWnd);

}

mainWindow, childClock은 정적으로 선언된 변수여서 WinMain 종료 직후 파괴자가 호출되는데 이때는 맵이 존재하지 않으므로 자신을 맵에서 제거할 필요도 없다. 오히려 제거하려고 하면 깔끔하게 정리하려다가 다운되어 버린다. WinMain 끝의 DeleteMap 호출문을 제거하면 이 조건문도 필요 없다.

이상으로 CWindow 클래스와 윈도우맵 관련 코드를 작성하고 테스트까지 마쳤다. 길지 않은 소스이지만 나름 정교하며 이런 코드를 확보하기 쉽지 않았다. 여러 번의 시행착오와 개선을 거쳐 약간 불편하지만 말썽없도록 만들었다. 생성, 파괴 순서만 잘 지키면 된다.