3.베타 2

가.버그수정

지금부터 베타 1의 버그를 수정하여 베타 2를 만들 것이다. 베타 1을 발표한 후 2주 정도 버그 보고를 기다렸으나 아무런 보고가 없어 개발자가 발견한 버그만 수정했다. 사실 훨씬 더 많은 버그가 있겠지만 아직 전혀 사용자를 확보하지 못했기 때문에 버그 보고도 제대로 못받고 있다. 버그가 많아서 사용자가 없고 그러다 보니 버그도 못 고치는 악순환이 계속되는데 이런 상황을 타계하기 위해서는 개발자 본인이 부지런한 것 외에는 다른 도리가 없는 것 같다.

버그를 발견할 때마다 실습 문서를 수정하여 해결할 수도 있고 실제로 베타 1까지는 이런 식으로 문서를 관리했지만 너무 번거롭다. 지금까지의 실습 프로젝트는 단계별로 되어 있어서 앞쪽을 수정하면 뒤쪽도 모두 같이 수정해야 하므로 시간이 너무 많이 걸린다. 그래서 베타 1까지의 실습 과정 문서는 버그가 있는 채로 그대로 유지하고 최종 버전만 수정하여 베타 2를 만들 것이다. 이 실습을 통해 어떤 이유로 버그가 발생하며 어떤 식으로 버그를 해결하는지를 경험해 보기 바란다.

버전 정보 표시

베타 1에서 베타 2로 버전이 바뀌므로 타이틀 바의 제목도 수정한다. 아무리 사소한 변화지만 이것도 일종의 업그레이드이므로 당연히 버전 표시를 해야 한다.

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance

,LPSTR lpszCmdParam,int nCmdShow)

{

....

hWnd=CreateWindow(lpszClass,"당근 Beta2",WS_OVERLAPPEDWINDOW | WS_VISIBLE |

WS_CLIPCHILDREN,

CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,

NULL,(HMENU)NULL,hInstance,NULL);

마찬가지로 프로그램 소개 대화상자의 스태틱도 베타 1에서 베타 2로 변경한다. 이후 버전이 변경될 때마다 이 두 군데는 계속 수정해야 한다. 차후에는 버전 리소스에서 읽어서 출력하는 것으로 변경할 계획이다. 그동안 작성을 연기해 두었던 도움말도 작성했으므로 도움말의 링크를 제공한다.

void OnCommand(HWND hWnd,WPARAM wParam,LPARAM lParam)

{

....

case IDM_HELP_INDEX:

ShellExecute(hWnd,"open","http://www.winapi.co.kr/project/dangeun/manual/manual.htm",NULL,NULL,SW_SHOW);

break;

관리 사이트의 고정된 URL로 이동했다. 이 페이지에 당근의 온라인 도움말을 제공하고 지속적으로 관리할 것이다. 오프라인으로 같이 배포되는 도움말은 당분간 제공하지 않는다.

대화상자 위치 조정

당근은 모든 대화상자를 부모의 중앙에 열며 이 처리를 MoveToParentCenter 함수가 담당한다. 그러나 이 함수의 논리가 너무 허술해서 대화상자가 안보이거나 타이틀 바가 숨겨지는 경우가 있다. 예를들어 메인 윈도우 높이를 아주 낮게 해 두고 화면 위쪽에서 대화상자를 호출할 때 대화상자 타이틀 바가 화면 위쪽에 배치된다. 부모보다 더 큰 자식이 부모의 중앙에 오려면 위쪽으로 올라갈 수밖에 없는 것이다.

더 심각한 경우도 있다. 부모의 높이를 아주 높게 해 두고 화면의 아래쪽으로 내려 윈도우가 화면 밖을 벗어나게 해 두고 대화상자를 열면 아예 보이지도 않는다. 키가 큰 부모의 중앙 위치를 찾다 보니 화면 바깥으로 벗어나 버리는 것이다. 이 상태에서는 마우스로 대화상자를 이동할 수 없으므로 어쩔 수 없이 키보드로 손이 가야 하므로 불편하다.

이렇게 되지 않으려면 부모의 중앙으로 일단 이동하되 자신의 일부가 화면에 가려져 있으면 모니터 안쪽으로 좌표를 조정해야 한다. 간단한 문제인 것 같지만 다중 모니터 환경까지 고려해야 하므로 조금 복잡하다. 이 함수를 다음과 같이 수정한다.

void MoveToParentCenter(HWND hWnd)

{

RECT wrt,crt;

HWND hParent;

RECT rt,irt;

HMONITOR hMon;

MONITORINFOEX mi;

hParent=GetParent(hWnd);

if (hParent == NULL) {

return;

}

if (IsIconic(hParent)) {

ShowWindow(hParent,SW_RESTORE);

}

GetWindowRect(hParent,&wrt);

GetWindowRect(hWnd,&crt);

rt.left=wrt.left+(wrt.right-wrt.left)/2-(crt.right-crt.left)/2;

rt.top=wrt.top+(wrt.bottom-wrt.top)/2-(crt.bottom-crt.top)/2;

rt.right=rt.left+(crt.right-crt.left);

rt.bottom=rt.top+(crt.bottom-crt.top);

// 많이 걸쳐진 모니터의 워크 에리어에 완전히 포함되어 있지 않으면 좌표를 조정한다.

hMon=MonitorFromWindow(hWnd,MONITOR_DEFAULTTOPRIMARY);

mi.cbSize=sizeof(MONITORINFOEX);

GetMonitorInfo(hMon,&mi);

IntersectRect(&irt,&rt,&mi.rcWork);

if (EqualRect(&irt,&rt)==FALSE) {

// 모니터 안으로 수직 이동

if (rt.top < mi.rcWork.top) {

rt.top=mi.rcWork.top;

} else if (rt.bottom > mi.rcWork.bottom) {

rt.top=mi.rcWork.bottom-(rt.bottom-rt.top);

}

// 모니터 안으로 수평 이동

if (rt.left < mi.rcWork.left) {

rt.left=mi.rcWork.left;

} else if (rt.right > mi.rcWork.right) {

rt.left=mi.rcWork.right-(rt.right-rt.left);

}

}

SetWindowPos(hWnd,HWND_NOTOPMOST,rt.left,rt.top,0,0,SWP_NOSIZE);

}

MonitorFromWindow 함수는 지정한 윈도우의 영역이 많이 걸친 모니터의 핸들을 구하며 GetMonitorInfo 함수는 모니터의 여러 가지 정보를 구한다. 모니터의 워크 에리어 좌표에 대화상자가 완전히 포함되는지를 점검해 본 후 그렇지 않다면 모니터 안쪽으로 대화상자의 좌표를 조정한다. 이제 어떤 경우라도 대화상자가 제대로 보일 것이다.

프로젝트 창의 높이

출력창, 파일창, 상용구 창이 모두 보이는 상태에서 메인 윈도우를 작게 축소하면 파일창의 일부분이 사라졌다가 다시 나타나는 이상한 증상을 보인다. 출력창이 보이는 상태에서 출력창 높이보다 메인 윈도우를 더 작게 점점 축소해 보면 확인할 수 있다.

이렇게 되는 이유는 상용구 창의 높이가 음수가 되고 그 나머지를 파일창의 높이로 계산하기 때문인데 다음 한 줄만 추가하면 된다.

void GetChildSize(int &t,int &s,int &f,int &o,int &w,int &ch)

{

....

// 클라이언트 영역이 음수인데 출력창이 보이는 상태면 출력창의 높이를 줄여

// 위쪽의 파일탭, 툴바 등과 닿지 않게 한다.

if (c < 0 && o) {

o=crt.bottom-(t+s+f+GAP);

c=0;

}

c는 MDI 클라이언트 영역의 높이인데 이 값이 음수가되면 출력 창의 높이를 조정하여 출력창이 위쪽의 툴바나, 파일탭과 겹치지 않게 한다. 이것은 당연한 조치이나 c가 음수인 상태를 그대로 방치하기 때문에 바로 아래쪽의 상용구 창 높이를 계산하는 식에서 ch가 음수가 된다. 이 값이 음수가 되면 파일창은 오히려 양수가 되어 사라졌다가 다시 보이는 것이다.

상태란의 폭 계산 버그

당근의 상태란은 고정되어 있지 않고 설정 대화상자에서 사용자가 보고자 하는 파트를 선택할 수 있으며 순서를 변경할 수도 있다. 이때 파트의 순서를 변경하면 폭을 제대로 계산하지 못하는 버그가 있는데 파트에 폭을 할당하는 루프에 문제가 있다.

void SetStatusPart()

{

....

if (g_ChildNum) {

// 보이는 모든 파트의 폭을 합함

for (i=0,TotalWidth=0;i<STNUM;i++) {

if (Option.StMask[i].bShow) {

TotalWidth+=Option.StMask[i].Width;

}

}

SBPart[0]=max(200,crt.right-TotalWidth);

// 순서에 따라 루프를 돈다.

for (i=0,Num=0;i<STNUM;i++) {

idx=Option.GetStNumByOrder(i);

if (idx != -1 && Option.StMask[idx].bShow) {

Num++;

SBPart[Num]=SBPart[Num-1]+Option.StMask[idx].Width;

}

}

SendMessage(hStatus, SB_SETPARTS, Num+1, (LPARAM)SBPart);

} else {

....

파트의 순서값으로 루프를 먼저 돌며 보이는 파트를 찾아 폭을 할당해야 하는데 보이는 파트를 먼저 찾고 이 파트의 순서값을 조사했기 때문에 엉뚱한 결과가 나온 것이다. 이전 코드와 비교해 보면 어디가 잘못되었는지 쉽게 알 수 있다. 역시 숙련자에게도 루프란 쉽지 않으며 실수의 여지가 많다.

편집 여부 이미지 관리

파일을 편집하면 파일탭의 이미지 색상이 변경되며 상태란의 편집여부 파트도 변경된다. 변경시점이 완전히 동일하기 때문에 파일탭의 이미지를 상태란 관리 루틴에서 함께 처리했다. 문제는 편집여부 파트를 숨길수도 있다는 점인데 이 파트가 숨겨지면 파일탭도 관리되지 않는다. 파일탭은 파트의 보이기 상태와 상관없이 따로 처리해야 한다.

void SetStatusText(int mask,LPCTSTR Mes/*=NULL*/)

{

....

// 파일탭의 이미지는 문서 편집 여부 상태란의 보이기와는 상관없이 처리한다.

if (mask & (1 << 2+1)) {

tie.mask=TCIF_IMAGE;

tie.iImage=pSi->Ae.GetModified();

idx=FindFileTab(pSi->NowFile);

if (idx!=-1) {

TabCtrl_SetItem(hFileTab,idx,&tie);

}

}

// 0번 상태란. stidx=정보 번호, bitmask=mask에서 해당 상태의 위치

for (stidx=0;stidx<STNUM;stidx++) {

if (!(mask & (1 << (stidx+1)) && Option.StMask[stidx].bShow)) {

continue;

}

switch (stidx) {

....

case 2:

if (pSi->Ae.GetModified()) {

lstrcpy(Text,"편집되었음");

} else {

lstrcpy(Text,"미편집");

}

break;

case 3:

....

시점은 아직도 일치하므로 SetStatusText 함수에서 파일탭의 이미지를 관리하되 파트의 보이기 상태를 점검하기 전에 2번 파트를 갱신하라는 신호가 왔으면 파일탭의 이미지를 변경한다. 이제 편집여부 파트를 숨겨도 파일탭이 잘 관리될 것이다.

탐색기 팝업 메뉴 버그

이 버그는 조금 황당한 면이 있는데 개발중에 탐색기의 팝업 메뉴가 종종 사라지는 것을 목격할 수 있었다. 옵션 관리 루틴을 집중적으로 점검해 보아도 별다른 이상을 발견하지 못했는데 원인은 엉뚱한 곳에 있다. 당근은 설치할 때 DgCmd.dll을 시스템 디렉토리로 복사하고 이 DLL의 탐색기에 등록한다.

설치해제할 때는 반대로 이 파일을 삭제해야 하는데 탐색기가 이 파일을 사용하고 있으므로 당장 삭제할 수는 없다. 그래서 다음 부팅할 때 삭제하도록 등록만 해 놓으며 이 과정을 정상적으로 밟으면 설치 해제도 잘 된다. 문제는 설치 해제 후 재부팅없이 다시 설치할 때인데 이때는 DgCmd.dll이 시스템 디렉토리에 이미 있더라도 다음 부팅할 때 삭제되어 버린다. 즉, 설치 해제에 의해 DgCmd.dll이 다음 부팅때 삭제되는 것이다.

최종 사용자들은 이런 증상을 경험할 기회가 사실 거의 없을 것이다. 그러나 개발중에 옵션 목록이 수시로 바뀔 때는 해제 후 재설치를 종종 해야 하므로 이런 증상을 쉽게 목격할 수 있다. 설치할 때 같은 세션에서 설치 해제된 적이 있으면 DgCmd.dll의 삭제를 취소해야 한다. 팝업 메뉴 등록 함수를 다음과 같이 수정한다.

void RegisterPopup(BOOL bReg,BOOL bDelete/*=FALSE*/)

{

TCHAR Pending[1024],*p;

....

osv.dwOSVersionInfoSize=sizeof(OSVERSIONINFO);

GetVersionEx(&osv);

if (bReg) {

if (bReg) {

// DLL 파일이 없으면 리소스에서 추출해서 만든다.

if (_access(DllPath,0) != 0) {

hRSrc=FindResource(g_hInst,MAKEINTRESOURCE(IDR_DLL1),"DLL");

Size=SizeofResource(g_hInst,hRSrc);

hMem=LoadResource(g_hInst,hRSrc);

ptr=LockResource(hMem);

hFile=CreateFile(DllPath,GENERIC_WRITE,0,NULL,

CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);

WriteFile(hFile,ptr,Size,&dwWritten,NULL);

CloseHandle(hFile);

}

// 취소 후 재설치될 때 삭제 등록된 정보를 취소한다.

if (osv.dwPlatformId == VER_PLATFORM_WIN32_NT) {

SHRegReadString(SHLM,"SYSTEM\\CurrentControlSet\\Control\\Session Manager",

"PendingFileRenameOperations","",Pending,1024);

p=strstr(Pending,"DgCmd.dll");

if (p) {

memcpy(p,"zzzzz.zzz",9);

}

SHRegWriteString(SHLM,"SYSTEM\\CurrentControlSet\\Control\\Session Manager",

"PendingFileRenameOperations",Pending);

} else {

WritePrivateProfileString("rename","NUL",NULL,"Wininit.ini");

}

RegisterSvr(DllPath,TRUE);

} else {

....

사용중인 파일을 삭제하는 방법이 9x 계열과 NT 계열에서 틀리므로 삭제를 취소하는 방법도 틀리다. 그래서 버전 조사 코드를 함수 앞쪽으로 이동하고 설치할 때 레지스트리에 삭제 등록된 DgCmd.dll이 있으면 이 값을 삭제한다. 삭제 등록된 파일이 DgCmd.dll뿐만 아니라 다른 프로그램이 등록해 놓은 파일도 있을 수 있으므로 레지스트리 키를 무조건 삭제해서는 안되며 DgCmd.dll만 삭제해야 한다.

레지스트리 값을 전부 읽어 DgCmd.dll을 삭제하고 다시 기록하면 되겠으나 이 키는 여러 개의 문자열이 개행 코드로 구분되어 있어서 그다지 간단하지가 않다. 여기서는 좀 더 간단한 방법을 사용했다. DgCmd.dll을 zzzzz.zzz라는 이름으로 바꿔 버리면 삭제에 실패하므로 아무 일도 일어나지 않을 것이다. 일종의 꽁수라고 할 수 있는데 별 말썽은 없다.

나.컨트롤의 독립성 개선

당근의 주 엔진인 ApiEdit는 처음부터 컨트롤로 디자인되어 다른 프로젝트에 재사용할 수 있도록 관리해 왔다. 그런데 막상 릴리즈한 후 다른 프로젝트에 사용해 보니 불편한 점도 있고 문제점도 있어 좀 더 독립성을 높일 필요가 있다.

커스텀 커서 생성

당근은 세 개의 커서 리소스를 사용한다. 컨트롤이 리소스를 가질 수는 없으므로 호스트로부터 이 리소스들을 받아서 사용해야 한다. 물론 기능상의 문제는 없지만 호스트 제작자가 당근의 소스로부터 리소스 세 개를 복사하고 RC 파일을 직접 열어 이 리소스를 추가해야 한다는 점은 재활용의 큰 문제점이다. 호스트는 아무런 추가 작업없이 컨트롤을 쓸 수 있어야 한다.

그렇다고 해서 커서를 쓰지 않을 수는 없으므로 컨트롤이 커서를 직접 만들어서 사용하는 방법을 쓰기로 한다. ApiEdit의 리소스를 로드하는 LoadAeResource 함수에서 커서를 아예 만들어 쓰도록 수정하자. 이미지 형태의 커서를 정의하려면 대량의 데이터들이 필요하다.

void CApiEdit::LoadAeResource()

{

static BYTE CopyAnd[]={

0XFF,0XFF,0XFF,0XFF,0X9F,0XFF,0XFF,0XFF, 0X8F,0XFF,0XFF,0XFF,0X87,0XFF,0XFF,0XFF,

0X83,0XFF,0XFF,0XFF,0X81,0XFF,0XFF,0XFF, 0X80,0XFF,0XFF,0XFF,0X80,0X7F,0XFF,0XFF,

0X80,0X3F,0XFF,0XFF,0X80,0X1F,0XFF,0XFF, 0X80,0X0F,0XFF,0XFF,0X80,0XFF,0XFF,0XFF,

0X88,0X7F,0XFF,0XFF,0X98,0X7F,0XFF,0XFF, 0XBC,0X3F,0XFF,0XFF,0XFC,0X3F,0XFF,0XFF,

0XFE,0X1F,0XFF,0XFF,0XF0,0X01,0X00,0X7F, 0XF0,0X01,0X00,0X7F,0XF3,0XD9,0X00,0X7F,

0XF3,0XF9,0X00,0X7F,0XF3,0XF9,0X00,0X7F, 0XF3,0XF9,0X00,0X7F,0XF0,0X01,0X00,0X7F,

0XF0,0X01,0X00,0X7F,0XFF,0XFF,0X00,0X7F, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

};

static BYTE CopyXor[]={

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X20,0X00,0X00,0X00,0X30,0X00,0X00,0X00,

0X38,0X00,0X00,0X00,0X3C,0X00,0X00,0X00, 0X3E,0X00,0X00,0X00,0X3F,0X00,0X00,0X00,

0X3F,0X80,0X00,0X00,0X3F,0XC0,0X00,0X00, 0X3E,0X00,0X00,0X00,0X36,0X00,0X00,0X00,

0X23,0X00,0X00,0X00,0X03,0X00,0X00,0X00, 0X01,0X80,0X00,0X00,0X01,0X80,0X00,0X00,

0X00,0XC0,0X00,0X00,0X04,0XD4,0X00,0X00, 0X0A,0X2A,0X7F,0X00,0X04,0X04,0X77,0X00,

0X08,0X02,0X77,0X00,0X04,0X04,0X41,0X00, 0X08,0X02,0X77,0X00,0X05,0X54,0X77,0X00,

0X0A,0XAA,0X7F,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

};

static BYTE MoveAnd[]={

0XFF,0XFF,0XFF,0XFF,0X9F,0XFF,0XFF,0XFF, 0X8F,0XFF,0XFF,0XFF,0X87,0XFF,0XFF,0XFF,

0X83,0XFF,0XFF,0XFF,0X81,0XFF,0XFF,0XFF, 0X80,0XFF,0XFF,0XFF,0X80,0X7F,0XFF,0XFF,

0X80,0X3F,0XFF,0XFF,0X80,0X1F,0XFF,0XFF, 0X80,0X0F,0XFF,0XFF,0X80,0XFF,0XFF,0XFF,

0X88,0X7F,0XFF,0XFF,0X98,0X7F,0XFF,0XFF, 0XBC,0X3F,0XFF,0XFF,0XFC,0X3F,0XFF,0XFF,

0XFE,0X1F,0XFF,0XFF,0XF0,0X01,0XFF,0XFF, 0XF0,0X01,0XFF,0XFF,0XF3,0XD9,0XFF,0XFF,

0XF3,0XF9,0XFF,0XFF,0XF3,0XF9,0XFF,0XFF, 0XF3,0XF9,0XFF,0XFF,0XF0,0X01,0XFF,0XFF,

0XF0,0X01,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

};

static BYTE MoveXor[]={

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X20,0X00,0X00,0X00,0X30,0X00,0X00,0X00,

0X38,0X00,0X00,0X00,0X3C,0X00,0X00,0X00, 0X3E,0X00,0X00,0X00,0X3F,0X00,0X00,0X00,

0X3F,0X80,0X00,0X00,0X3F,0XC0,0X00,0X00, 0X3E,0X00,0X00,0X00,0X36,0X00,0X00,0X00,

0X23,0X00,0X00,0X00,0X03,0X00,0X00,0X00, 0X01,0X80,0X00,0X00,0X01,0X80,0X00,0X00,

0X00,0XC0,0X00,0X00,0X04,0XD4,0X00,0X00, 0X0A,0X2A,0X00,0X00,0X04,0X04,0X00,0X00,

0X08,0X02,0X00,0X00,0X04,0X04,0X00,0X00, 0X08,0X02,0X00,0X00,0X05,0X54,0X00,0X00,

0X0A,0XAA,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

};

static BYTE MarginAnd[]={

0XFF,0XFF,0X7F,0XFF,0XFF,0XFF,0X3F,0XFF, 0XFF,0XFF,0X1F,0XFF,0XFF,0X00,0X0F,0XFF,

0XFF,0X00,0X07,0XFF,0XFF,0X00,0X03,0XFF, 0XFF,0X00,0X07,0XFF,0XFF,0X00,0X0F,0XFF,

0XFF,0XFF,0X1F,0XFF,0XFF,0XFF,0X3F,0XFF, 0XFF,0XFF,0X7F,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF, 0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,0XFF,

};

static BYTE MarginXor[]={

0X00,0X00,0X80,0X00,0X00,0X00,0XC0,0X00, 0X00,0X00,0XA0,0X00,0X00,0XFF,0X90,0X00,

0X00,0X80,0X08,0X00,0X00,0X80,0X04,0X00, 0X00,0X80,0X08,0X00,0X00,0XFF,0X90,0X00,

0X00,0X00,0XA0,0X00,0X00,0X00,0XC0,0X00, 0X00,0X00,0X80,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00, 0X00,0X00,0X00,0X00,0X00,0X00,0X00,0X00,

};

hCSel=LoadCursor(NULL,IDC_ARROW);

hCNoDrop=LoadCursor(NULL,IDC_NO);

hCCopy=CreateCursor(g_hInst,1,1,32,32,CopyAnd,CopyXor);

hCMove=CreateCursor(g_hInst,1,1,32,32,MoveAnd,MoveXor);

hCMargin=CreateCursor(g_hInst,21,5,32,32,MarginAnd,MarginXor);

hLineNumFont=CreateFont(12,0,0,0,0,0,0,0,HANGEUL_CHARSET,3,2,1,

VARIABLE_PITCH | FF_MODERN,"굴림");

}

void CApiEdit::UnLoadAeResource()

{

DestroyCursor(hCCopy);

DestroyCursor(hCMove);

DestroyCursor(hCMargin);

DeleteObject(hLineNumFont);

}

커서는 CreateCursor 함수로 생성하는데 AND 마스크와 XOR 마스크를 제공해야 한다. 모눈 종이에 원하는 그림을 그린 후 AND 마스크는 투명 부분만 1로 평가하고 XOR 마스크는 흰색만 1로 평가하여 2진수를 추출한 후 16진수로 다시 바꾸면 된다. 이런 작업은 어셈블리 코딩을 해 본 경험을 필요로 하므로 사실 무척 생소할 것이다. 이렇게 두 개의 배열을 정의한 후 CreateCursor 함수를 호출하면 커서 핸들이 리턴된다. 이렇게 만든 커서는 DestroyCursor 함수로 직접 삭제해야 한다.

리소스 편집기에서 편리하게 만들 수 있는 커서를 왜 이렇게 복잡한 방법으로 만들까 싶지만 운영체제가 제공하는 API 함수들을 다 요긴하게 사용할 곳이 있다. 컨트롤이 직접 커서를 만들어서 사용하므로 호스트는 부담을 지지 않아도 된다. 이제 세 개의 커서 리소스는 불필요하므로 제거한다. 이왕 리소스에 손 댄김에 액셀러레이터 테이블도 제거해 버린다. 당근은 별도의 단축키 알고리즘을 사용하므로 액셀러레이터가 필요치 않다.

분석기의 옵션 설정

여기까지 작업된 상태에서 ApiEdit를 다른 프로젝트로 가져가 보면 에러가 하나 발생한다. 옵션을 관리하는 주체가 호스트이므로 호스트가 분석기의 색상 옵션을 설정하는데 호스트가 바뀌면 이 과정이 없기 때문이다. 파일을 열 때 OpenFileToChild 함수에서 SelectParser 함수를 호출하며 뷰를 분할할 때도 옵션을 설정해야 하는데 CloneView에서 수행하고 있다.

// 뷰를 복제한다.

void CApiEdit::CloneView(CApiEditText *pDest, CApiEditText *pSrc,int SplitType)

{

....

// 분석기 지정

pDest->SetParser((int)pSrc->GetParser()->GetInfo(0));

Option.SetStyleColor(pDest->GetParser());

SendMessage(GetParent(hWnd),UserBase+6,0,(LPARAM)pDest->GetParser());

이 함수에서 Option 객체의 SetStyleColor 함수를 호출하여 분석기의 옵션을 설정하는데 잘 보면 말도 안되는 소리다. ApiEdit 컨트롤이 Option 객체를 어떻게 아는가? 모든 호스트가 이런 옵션을 유지한다는 보장이 없으므로 호스트에게 메시지로 요청해야 한다. lParam으로 분석기 객체의 포인터를 실어 UserBase+6번 메시지를 보냈다.

LRESULT CALLBACK DGChildProc(HWND hWnd,UINT iMessage,WPARAM wParam,LPARAM lParam)

{

....

if (pSi && iMessage > WM_USER) {

....

// lParam으로 전달된 분석기의 설정을 변경하라.

if (iMessage == pSi->Ae.GetUserBase()+6) {

Option.SetStyleColor((CParse *)lParam);

return 0;

}

}

호스트는 이 메시지를 받았을 때 자신이 유지하고 있는 옵션 정보대로 분석기의 색상을 변경하면 된다. 만약 호스트가 이 메시지를 처리하지 않더라도 ApiEdit는 디폴트 설정대로 구문 분석을 할 수 있다. 여기까지 작업하면 ApiEdit는 재사용성이 훨씬 더 높아지며 파일만 복사해서 프로젝트에 포함하면 쉽게 재사용할 수 있다.

다.스타일 통합

ApiEdit 컨트롤은 사용자가 선택할 수 있는 옵션들이 아주 많다. 그만큼 풍부한 커스텀화를 지원한다는 뜻이며 다양한 환경에 두루 사용될 수 있어 활용성도 높다. 그러나 옵션을 관리하기 위한 함수들도 너무 많아 공개된 인터페이스가 많은 것은 또 다른 단점이라고 할 수 있다. 개별 변수로 되어 있는 옵션들을 비트 필드의 스타일로 바꿔 보자.

개별 변수는 개당 4바이트씩을 차지하는데 비해 비트 필드로 된 스타일은 단 1비트만 사용하므로 용량에 유리하다. 개별 변수는 용량도 많이 차지할 뿐만 아니라 일일이 Get/Set 함수를 제공해야 한다는 점이 불리하며 레지스트리 입출력도 개별적으로 해야 한다. 스타일은 통합 액세스 함수를 제공할 수 있고 레지스트리 입출력도 아주 간편하다. ApiEdit에서 비트 필드로 만들만한 스타일은 아주 많다. 일단 다음 스타일들을 ApiEdit.h에 정의한다.

// 컨트롤의 스타일

#define AES_WANTTAB 0x00000001

#define AES_USELINEEND 0x00000002

#define AES_ALLOWDRAG 0x00000004

#define AES_SPACEFORTAB 0x00000008

#define AES_AUTOINDENT 0x00000010

#define AES_BLOCKINDENTWITHTAB 0x00000020

#define AES_HOMETOFIRSTCHAR 0x00000040

#define AES_HIDECURLINE 0x00000080

#define AES_CALCTABWITHAVG 0x00000100

#define AES_HORZSPLITABLE 0x00000200

#define AES_VERTSPLITABLE 0x00000400

#define AES_AUTOCONVERT 0x00000800

#define AES_FIXEDCOLUMN 0x00001000

#define AES_NOWRAPCOLUMN 0x00002000

#define AES_USEAUTOCLIP 0x00004000

#define AES_AUTOCLIPBYTAB 0x00008000

#define AES_SHOWMARGIN 0x00010000

#define AES_SHOWENTER 0x00020000

#define AES_SHOWTAB 0x00040000

#define AES_SHOWSPACE 0x00080000

#define AES_SHOWLINENUM 0x00100000

#define AES_SHOWRULER 0x00200000

#define AES_SWAPDRAGBUTTON 0x00400000

#define AES_SMARTSPACE 0x00800000

#define AES_NOFIRSTSPACE 0x01000000

BOOL형의 옵션 변수들이 모두 스타일로 전환되었다. 정수형 옵션도 합칠 수 있지만 마스크를 관리해야 하므로 BOOL형보다는 훨씬 더 번거롭다. 스타일을 저장하는 변수와 읽고 쓰는 함수 4개를 다음과 같이 작성한다.

class CApiEdit : public CWindow

{

....

DWORD Style;

....

DWORD GetStyle() { return Style; }

void SetStyle(DWORD aStyle);

BOOL TestStyle(DWORD aStyle) { return (Style & aStyle) != 0; }

void ChangeStyle(DWORD aStyle, BOOL bCheck) {

if (bCheck) SetStyle(Style | aStyle); else SetStyle(Style & ~aStyle);

}

Style이 DWORD형이므로 최대 32개의 스타일을 하나의 변수에 저장할 수 있다. 액세스 함수들은 스타일 전체를 읽고 쓰는 함수와 개별 비트를 읽고 쓰는 함수 두 개가 제공된다. SetStyle 함수는 스타일 변경에 대한 부가 처리까지 해야 하므로 길이가 조금 길다.

// 변경된 스타일에 대한 효과를 적용한다.

void CApiEdit::SetStyle(DWORD aStyle)

{

DWORD Old=Style;

Style=aStyle;

if ((Old & AES_HIDECURLINE) != (Style & AES_HIDECURLINE)) {

ForAllView(Invalidate(-1))

}

if ((Old & AES_CALCTABWITHAVG) != (Style & AES_CALCTABWITHAVG)) {

ForAllView(SetTabWidth(arView[aet]->GetTabWidth()))

}

// 분할 가능성 변경은 분할된 상태에서는 조정할 수 없다.

if (arView[1]==NULL && (Old & AES_HORZSPLITABLE) != (Style & AES_HORZSPLITABLE)) {

AdjustSplitable();

}

if (arView[1]==NULL && (Old & AES_VERTSPLITABLE) != (Style & AES_VERTSPLITABLE)) {

AdjustSplitable();

}

if ((Old & AES_SHOWMARGIN) != (Style & AES_SHOWMARGIN)) {

for (int aet=0;aet<4 && arView[aet];aet++) {

arView[aet]->MarginWidth=(Style & AES_SHOWMARGIN) ? 25:0;

arView[aet]->Invalidate(-1);

SendMessage(arView[aet]->hWnd,WM_SIZE,SIZE_RESTORED,(LPARAM)0);

}

}

if ((Old & AES_SHOWENTER) != (Style & AES_SHOWENTER)) {

ForAllView(Invalidate(-1))

}

if ((Old & AES_SHOWTAB) != (Style & AES_SHOWTAB)) {

ForAllView(Invalidate(-1))

}

if ((Old & AES_SHOWSPACE) != (Style & AES_SHOWSPACE)) {

ForAllView(Invalidate(-1))

}

if ((Old & AES_SHOWLINENUM) != (Style & AES_SHOWLINENUM)) {

ForAllView(Invalidate(-1))

}

if ((Old & AES_SHOWRULER) != (Style & AES_SHOWRULER)) {

for (int aet=0;aet<4 && arView[aet];aet++) {

arView[aet]->Invalidate(-1);

SendMessage(arView[aet]->hWnd,WM_SIZE,SIZE_RESTORED,(LPARAM)0);

}

}

if ((Old & AES_NOFIRSTSPACE) != (Style & AES_NOFIRSTSPACE)) {

for (int aet=0;aet<4 && arView[aet];aet++) {

arView[aet]->UpdateLineInfo();

arView[aet]->UpdateScrollInfo();

arView[aet]->SetCaret();

arView[aet]->Invalidate(-1);

}

}

}

스타일 비트를 점검하여 변경된 스타일에 대해서는 부가적인 처리를 해야 한다. 예를 들어 제어 코드 보이기 스타일이 변경되었면 모든 뷰를 다시 그려야 하고 정렬 관련 스타일이 변경되었으면 정렬도 다시 해야 한다.

개별 변수로 되어 있던 옵션들이 스타일로 바뀌었으므로 전체 소스에서 이 변수들을 제거하고 스타일을 참조하도록 변경해야 한다. 아주 대량의 소스 편집 작업이 필요한데 대표적으로 bAllowDrag 옵션을 스타일로 변경하는 절차를 보자. 소스에서 bAllowDrag라는 모든 명칭을 전부 스타일로 바꿔야 한다. ApiEdit.h의 다음 세 줄을 삭제한다.

class CApiEdit : public CWindow

{

....

BOOL bAllowDrag;

....

BOOL GetAllowDrag() { return bUseLineEnd; }

void SetAllowDrag(BOOL aAllowDrag) { bAllowDrag=aAllowDrag; }

액세스 함수가 인라인이 아니면 구현 파일의 Get/Set 함수 코드도 물론 삭제해야 한다. ApiEdit.cpp에는 이 변수를 초기화하는 코드가 있는데 역시 삭제하고 대신 Style 변수에 이 비트를 초기화한다.

CApiEdit::CApiEdit()

{

....

Style=AES_WANTTAB | AES_ALLOWDRAG | AES_AUTOINDENT | AES_BLOCKINDENTWITHTAB |

AES_HOMETOFIRSTCHAR | AES_HIDECURLINE | AES_CALCTABWITHAVG | AES_HORZSPLITABLE |

AES_VERTSPLITABLE | AES_AUTOCONVERT | AES_USEAUTOCLIP | AES_AUTOCLIPBYTAB |

AES_SHOWMARGIN;

다른 옵션들도 마찬가지로 디폴트가 TRUE인 모든 옵션의 스타일을 한꺼번에 설정하면 된다. 이 스타일을 참조하는 모든 곳도 수정해야 한다. bAllowDrag는 딱 한 군데서만 참조하고 있으므로 수정하기도 쉽다.

void CApiEditText::OnLButtonDown(HWND hWnd, BOOL fDoubleClick, int x, int y, UINT keyFlags)

{

....

if (IsInSelection(x+xPos, y+yPos) && pFrame->bReadOnly==FALSE && pFrame->TestStyle(AES_ALLOWDRAG)) {

pFrame->bAllowDrag가 pFrame->TestStyle(AES_ALLOWDRAG)로 수정되었다. 프레임의 변수를 직접 참조하는 것이 아니라 TestStyle 함수로 해당 옵션을 의미하는 비트가 설정되어 있는지를 조사하면 된다. 이 스타일을 관리하는 코드들도 모두 수정된다. 설정 대화상자의 참조문들도 같은 방식으로 수정한다.

BOOL CALLBACK EditDlgProc(HWND hDlg,UINT iMessage,WPARAM wParam,LPARAM lParam)

{

....

CheckDlgButton(hDlg,IDC_ALLOWDRAG,NewOption.TestStyle(AES_ALLOWDRAG));

....

NewOption.ChangeStyle(AES_ALLOWDRAG,IsDlgButtonChecked(hDlg,IDC_ALLOWDRAG));

스타일을 적용하는 ApplyNow와 SetSetting에서는 스타일을 개별적으로 적용할 필요없이 모든 스타일에 대해 SetStyle 함수만 호출하면 된다.

void ApplyNow()

{

....

// 스타일이 변경되었으면 적용한다.

if (Option.GetStyle() != NewOption.GetStyle()) {

Option.SetStyle(NewOption.GetStyle());

pSi->Ae.SetStyle(NewOption.GetStyle());

}

Option 구조체도 ApiEdit와 마찬가지로 bAllowDrag는 없애고 Style 변수와 액세스 함수만 추가한다. 레지스트리에 개별 변수를 입출력하는 코드도 모두 삭제하고 Style 변수만 입출력하면 된다. 나머지 옵션들도 모두 같은 절차대로 수정하되 옵션에 따라 수정 방법이 조금씩 달라진다. 부가 효과가 있는 스타일은 SetStyle에서 효과를 처리해야 하며 MarginWidth처럼 옵션이면서 동시에 폭을 저장하는 변수는 관리하는 방법이 조금 다르다.

색상 관련 변수와 함수들도 모두 통합한다. cFore, cBack, MarkColor, RulerColor 등 13개의 색상 관련 변수가 있고 이 변수들을 액세스하는 Get/Set 함수들이 개별적으로 존재하는데 하나의 배열과 두 개의 함수로 통합할 수 있다.

// 색상 번호

enum { AECOLOR_MAR1, AECOLOR_MAR2, AECOLOR_NUM, AECOLOR_MARK, AECOLOR_CODE,

AECOLOR_CUR, AECOLOR_FORE, AECOLOR_BACK, AECOLOR_SELFORE, AECOLOR_SELBACK,

AECOLOR_INNERRECT, AECOLOR_RULER, AECOLOR_SELFRAME };

#define AECOLORS 13

class CApiEdit : public CWindow

{

....

COLORREF Color[AECOLORS];

....

COLORREF GetColor(int index);

void SetColor(int index, COLORREF aColor);

색상을 참조하는 모든 곳에서 변수 대신 GetColor와 색상 인덱스를 사용한다. 예를 들어 전경색이 필요하면 pFrame->GetColor(AECOLOR_FORE) 호출문으로 전경색을 조사한다. 색상 설정 대화상자도 대량의 코드 편집이 필요하다. 여기까지 스타일 통합과 색상 변수들 통합 작업을 마치면 소스는 630줄이나 줄어들고 실행 파일 크기도 작아지며 속도도 빨라지고 레지스트리도 훨씬 덜 사용한다. 뿐만 아니라 컨트롤의 사용자도 함수를 개별적으로 익히는 것보다 스타일을 익히는 것이 더 쉬우므로 인터페이스도 훨씬 더 좋아졌다.

하지만 이렇게 되면 이제 당근은 더 이상 실습 과정을 보일 수가 없게 되었다. 스타일 통합을 위해 약 12시간에 걸친 소스 대수술을 했는데 이 실습 절차를 지면에 일일이 보인다는 것은 불가능하다. 베타 1까지는 단계별로 실습을 진행해 왔지만 이제는 더 이상 이런 단계 실습 방식으로 코드를 관리하는 것이 어려우며 사실 필요치도 않다. 스타일 통합 과정에서 일부 옵션 조정 버그도 수정했으며 색상값과 컨트롤의 순서를 맞추기 위해 리소스의 컨트롤 ID도 조정했다. 탭, 공백, 개행코드 표시 스타일(ShowTabType 등)은 원래 뷰의 멤버였으나 이번 작업때 프레임의 멤버로 옮겼다.

기능들을 지속적으로 확장하다 보면 중간 중간에 소스의 구조를 바꾸거나 고쳐야 하는 일은 아주 흔하다. 그러나 당근은 실습 프로젝트라는 특성 때문에 중간에 구조를 고칠 기회가 전혀 없었고 그러다 보니 개발 기간도 더 늘어날 수밖에 없었다. 문서와 함께 제공되는 실습 프로젝트는 베타 1이 마지막이며 베타 2 이후부터는 어디에 어떤 코드를 추가했는지 따위의 설명 문서는 더 이상 작성할 수가 없다. 당근 1.2 이후에도 소스와 제작 기술은 공개할 생각이지만 실습 과정 문서는 더 이상 작성하지 않으므로 앞으로는 소스 프로젝트를 통해 기술을 스스로 추출해 낼 수 있어야 한다.