베타1을 릴리즈하기 전에 간단한 최적화 몇 가지를 할 것이다. 성능 개선에 큰 도움이 되는 몇 가지 최적화거리가 있기는 하지만 이런 것들은 좀 더 기능이 완성된 후에 하는 것이 코드 유지에 유리해 다음으로 연기하고 아주 간단한 최적화만 할 것이다.
당근의 기본 문자열 출력 함수는 클리핑 기능과 자간 조절 기능이 있는 ExtTextOut이다. 단, 몇 가지 문제로 인해 이 함수를 직접 사용하지 않고 AeTextOut이라는 함수를 대신 사용하는데 이 함수의 코드를 보자.
void CApiEditText::AeTextOut(HDC hdc,int x,int y,TCHAR *str,int len)
{
int i;
int *lpDx;
int boff;
boff=str-pFrame->buf;
lpDx=(int *)malloc(len*sizeof(int));
for (i=0;i<len;) {
if (pFrame->IsDBCS(boff+i)) {
lpDx[i++]=GetCharWidth(str+i,2);
lpDx[i++]=0;
} else {
lpDx[i++]=GetCharWidth(str+i,1);
}
}
ExtTextOut(hdc,x,y,0,NULL,str,len,lpDx);
free(lpDx);
}
lpDx 배열에 각 문자의 수평 위치를 미리 구해 놓고 한꺼번에 출력한다. 각 문자의 폭을 누적하여 다음 글자의 위치를 구하는데 이 과정에서 자간과 단어 간격 등의 옵션이 적용된다. 이 함수는 lpDx 배열을 매번 문자열 길이만큼 할당하고 해제하는데 큰 메모리는 아니지만 호출 회수가 너무 빈번하기 때문에 성능에 막대한 영향을 미친다. 매번 할당하는 것보다 미리 할당해 놓고 계속 사용하는 것이 좋다.
class CApiEditText : public CWindow
{
....
int *lpDx;
BOOL CApiEditText::OnCreate(HWND hWnd, LPCREATESTRUCT lpCreateStruct)
{
....
lpDx=(int *)malloc(1025*sizeof(int));
return TRUE;
}
void CApiEditText::OnDestroy(HWND hWnd)
{
....
free(lpDx);
}
lpDx를 뷰의 멤버로 선언하고 뷰가 생성될 때 1025의 크기로 미리 할당했으며 파괴될 때 해제한다. 이렇게 되면 뷰가 존재하는 동안 lpDx가 존재하므로 AeTextOut 함수에서 일일이 lpDx를 할당할 필요가 없다. 이 함수의 lpDx 관리 코드는 모두 삭제한다. 단, 이렇게 되면 AeTextOut 함수는 한 번에 출력할 수 있는 문자열 길이에 제약이 생기는데 DrawLine 함수에서 세그먼트 크기를 1024로 줄인다.
int CApiEditText::DrawLine(HDC hdc, int Line)
{
....
for (;;) {
for (len=0;;) {
assert(nowoff+len <= pLine[Line].End);
if (nowoff+len == pLine[Line].End || len >= 1024) {
원래 이 값은 4096이었는데 조금 더 줄였다. DrawLine에서 1024 이상일 때 세그먼트를 자르는데 lpDx는 왜 1025인가 하면 1023 위치가 DBCS이면 재수없게 1024를 넘을 수도 있기 때문이며 그래서 1바이트의 여유가 필요하다.
ApiEdit는 연속으로 입력되는 문자열의 취소 레코드를 병합한다. 매 글자나 음소마다 취소 레코드를 작성할 수는 없으므로 병합 처리는 생략할 수 없다. 그러나 클립보드에서 문자열을 연속적으로 붙여 넣으면 각 문자열들이 모두 병합되어 한 번에 붙여 넣어진 것처럼 기록된다. 이 상태에서 Ctrl+Z로 취소하면 붙여넣어진 모든 문자열이 한꺼번에 취소되어 불편하다. 입력 레코드를 적당히 병합하기는 하되 너무 길지 않도록 관리하는 것이 좋을 것 같다.
void CApiEdit::URInsert(int nPos, TCHAR *str, int len)
{
if (CanRedo()) {
ClearRedo();
} else {
if (pUR[nowur].action==UR_INSERT) {
// 삽입 위치가 연속이고 길이가 64 미만일 때만 병합한다.
if (pUR[nowur].pos + pUR[nowur].len==nPos && pUR[nowur].len < 64) {
AllocURData(nowur,pUR[nowur].len+len,5);
memcpy(pUR[nowur].data+pUR[nowur].len,str,len);
pUR[nowur].len+=len;
// 입력된 문자열이 공백이나 개행 코드이면 분할한다.
if (str[0]==' ' || str[0]=='\r') {
NextRecord();
}
return;
} else {
....
같은 삽입 레코드이고 위치가 연속적이더라도 이전 레코드의 길이가 64 미만일 때만 병합한다. 이때 64라는 값은 단순한 임의값인데 공백이나 개행없이 이 정도 문자열을 계속 입력할 리가 없으므로 이 정도 길이의 문자열이 들어 있다면 이전에 클립보드에서 붙여진 것으로 판단하는 것이다. 설사 이 판단이 틀렸다 하더라도 취소 레코드만 분할될 뿐 특별한 부작용은 없다.
당근은 사용자가 설정한 옵션을 레지스트리에 철저히 기록한다. 메인 윈도우가 파괴되는 시점인 OnDestroy에 다음과 같은 코드가 있다.
void OnDestroy(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
Option.Save(KEY);
DgMacro.SaveToReg(KEY);
DgShortCut.Save(KEY);
....
옵션, 매크로, 단축키 등을 모두 레지스트리에 저장한다. 문제는 이 함수들의 안쪽이 너무 거대해서 레지스트리에 굉장히 많은 값들을 기록한다는 것이다. 값이 조금이라도 변경되었다면 저장하는 것이 마땅하겠지만 그렇지 않다면 똑같은 값을 불필요하게 기록하며 종료 속도도 느려지고 운영체제도 레지스트리 캐시에 많은 자원을 낭비할 것이다. 실제로 값이 바뀔 때만 저장하는 것이 효율적인데 값 변경 여부를 조사하기 위한 멤버를 추가한다.
struct SOption
{
BOOL bModified;
....
SOption::SOption()
{
int i;
for (i=0;i<sizeof(arFtp)/sizeof(arFtp[0]);i++) {
lstrcpy(arFtp[i].Name,"");
}
Init();
bModified=FALSE;
}
class CMacro
{
public:
CMacro();
~CMacro();
SMacro *arMacro;
int Size;
int Num;
BOOL bModified;
CMacro::CMacro()
{
Size=0;
Num=0;
arMacro=NULL;
bModified=FALSE;
}
class CShortCut
{
public:
SShortCut *arShortCut;
BOOL bModified;
CShortCut::CShortCut()
{
arShortCut=NULL;
bModified=FALSE;
}
각 클래스에 bModified 멤버를 추가하고 생성자에서 FALSE로 초기화한다. 그리고 이 구조체가 조금이라도 변경될 때 TRUE로 변경한다. 옵션의 경우는 다음 한 줄만 작성하면 된다.
void Config()
{
PROPSHEETPAGE psp[11];
PROPSHEETHEADER psh;
NewOption=Option;
NewOption.bModified=TRUE;
....
NewOption의 bModified를 TRUE로 초기화하면 ApplyNow에서 이 구조체를 Option에 대입할 것이다. 사용자가 기본 설정 대화상자를 열어서 옵션은 변경하지 않고 바로 닫았다면 Option은 변하지 않는다. 설사 옵션을 변경했다 하더라도 취소 버튼을 눌러 NewOption을 Option으로 대입하지 않으면 모든 옵션 변경은 무효가 된다. 단축키와 매크로는 관리 대화상자를 열 때 변경된 것으로 간주한다.
void OnCommand(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
case IDM_TOOL_MACRO:
DgMacro.bModified=TRUE;
DgShortCut.bModified=TRUE;
DialogBox(g_hInst,MAKEINTRESOURCE(IDD_MACRO),hWnd,MacroDlgProc);
break;
case IDM_TOOL_SHORTCUT:
DgShortCut.bModified=TRUE;
DialogBox(g_hInst,MAKEINTRESOURCE(IDD_SHORTCUTLIST),hWnd,ShortCutListProc);
break;
대화상자를 열지 않고 단축키나 매크로를 편집할 수는 없으므로 이 길목을 지키고 있으면 변경 시점을 확실히 알 수 있다. 물론 대화상자를 단순히 열기만 하고 바로 닫아도 변경된 것으로 간주하는데 이렇게 되면 불필요하게 레지스트리에 중복 저장하겠지만 그렇다고 해서 별 부작용은 없다. 실제로 매크로와 단축키가 편집되었는지를 정확하게 판단하는 것도 가능은 하겠지만 그다지 정확할 필요도 없다. 옵션들이 변경되는 또다른 시점은 최초 설치될 때이다.
int OnCreate(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
if (SHRegReadInt(SHCU,KEY"Setting","StartAction",1000) == 1000) {
Option.GetStyleColor();
DgShortCut.Init();
FindFlag=AE_FIND_WRAP | AE_FIND_RECURSIVE | AE_FIND_SHORTPATH;
arFind[3].num=2;
arFind[3].Set(0,"*.*");
arFind[3].Set(1,"*.cpp;*.hpp;*.c;*.h;*.inl");
Option.bModified=TRUE;
DgMacro.bModified=TRUE;
DgShortCut.bModified=TRUE;
} else {
....
최초 설치시는 레지스트리에서 값을 읽지 않고 별도의 초기화 함수를 호출하는데 이때는 사용자가 직접 편집하지 않았더라도 종료할 때 무조건 옵션을 저장해야 한다. 각 클래스가 변경 여부를 스스로 관리하므로 종료시의 옵션 저장 코드는 다음과 같이 작성하면 된다.
void OnDestroy(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
// 저장할 필요가 있을 때만 저장한다.
if (Option.bModified) Option.Save(KEY);
if (DgMacro.bModified) DgMacro.SaveToReg(KEY);
if (DgShortCut.bModified) DgShortCut.Save(KEY);
....
실제로 변경된 옵션에 대해서만 레지스트리에 저장했다. 이렇게 하면 종료 속도가 훨씬 더 빨라진다.
교육용 프로젝트를 개발하다 보니 단계순으로 실습을 진행할 수밖에 없고 그러다 보니 소스가 무척이나 지저분한 곳이 있다. 대표적으로 Dangeun.cpp의 OnInitMenu 함수를 들 수 있는데 메뉴 항목이 매번 한 두개씩 개별적으로 추가되고 그렇다 보니 이 메뉴 항목을 관리하는 코드도 개별적으로 추가되어 완전히 엉망이 되어 버렸다. 다음과 같이 깔끔하게 정리하자.
#define DGCHECKMENUITEM(ID,Con) CheckMenuItem(hMenu,ID, MF_BYCOMMAND | ((Con) ? MF_CHECKED:MF_UNCHECKED))
#define DGENABLEMENUITEM(ID,Con) EnableMenuItem(hMenu,ID, MF_BYCOMMAND | ((Con) ? MF_ENABLED:MF_GRAYED))
void OnInitMenu(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
HMENU hMenu;
HWND hActive;
SInfo *pSi;
int s,e;
CApiEditText *pView;
BOOL bHexa,bText,bSel;
hMenu=(HMENU)wParam;
UpdateMenuCaption(hMenu);
hActive=(HWND)SendMessage(g_hMDIClient,WM_MDIGETACTIVE,0,NULL);
if (hActive) {
pSi=(SInfo *)GetWindowLongPtr(hActive,0);
pView=pSi->Ae.GetActiveView();
// 헥사 뷰와 선택영역 유무 미리 조사
bHexa=(pView->ViewType==HEXA_VIEW);
bText=(pView->ViewType==TEXT_VIEW);
pSi->Ae.GetSelect(s,e);
bSel=(s != e);
DGENABLEMENUITEM(IDM_EDIT_VIRT,bText);
DGENABLEMENUITEM(IDM_EDIT_COLUMN,bText);
DGENABLEMENUITEM(IDM_TOOL_PARA,bText);
DGCHECKMENUITEM(IDM_EDIT_VIRT,pView->GetVirtualPos() && bText);
DGCHECKMENUITEM(IDM_EDIT_COLUMN,pView->GetColumnMode() && bText);
DGCHECKMENUITEM(IDM_VIEW_HEXA,bHexa);
DGCHECKMENUITEM(IDM_FILE_READONLY,pSi->Ae.GetReadOnly());
DGENABLEMENUITEM(IDM_FILE_REVERT,pSi->Ae.GetModified() &&
strncmp(pSi->NowFile,"이름없음",8)!=0);
DGENABLEMENUITEM(IDM_EDIT_CUT,bSel);
DGENABLEMENUITEM(IDM_EDIT_COPY,bSel);
DGENABLEMENUITEM(IDM_EDIT_CUTAPPEND,bSel);
DGENABLEMENUITEM(IDM_EDIT_COPYAPPEND,bSel);
DGENABLEMENUITEM(IDM_EDIT_UPPERSENT,bSel);
DGENABLEMENUITEM(IDM_EDIT_TOTAB,bSel && !bHexa);
DGENABLEMENUITEM(IDM_EDIT_TOSPACE,bSel && !bHexa);
DGENABLEMENUITEM(IDM_EDIT_PASTE,IsClipboardFormatAvailable(CF_TEXT)==FALSE);
DGCHECKMENUITEM(IDM_VIEW_WORDWRAP,pSi->Ae.GetWrap() != 0);
DGCHECKMENUITEM(IDM_VIEW_CODE,pSi->Ae.GetShowState(SHOWENTER));
// 줄간 표시
for (s=IDM_LINE_1;s<=IDM_LINE_5;s++) DGCHECKMENUITEM(s,FALSE);
switch (pSi->Ae.GetLineRatio()) {
case 100:DGCHECKMENUITEM(IDM_LINE_1,TRUE);break;
case 120:DGCHECKMENUITEM(IDM_LINE_2,TRUE);break;
case 150:DGCHECKMENUITEM(IDM_LINE_3,TRUE);break;
case 200:DGCHECKMENUITEM(IDM_LINE_4,TRUE);break;
case 300:DGCHECKMENUITEM(IDM_LINE_5,TRUE);break;
}
DGENABLEMENUITEM(IDM_EDIT_UNDO,pSi->Ae.CanUndo());
DGENABLEMENUITEM(IDM_EDIT_REDO,pSi->Ae.CanRedo());
// 문법 표시
for (s=IDM_SYN_NONE;s<=IDM_SYN_SQL;s++) DGCHECKMENUITEM(s,FALSE);
switch (int(pSi->Ae.GetParser()->GetInfo(0))) {
case 0:DGCHECKMENUITEM(IDM_SYN_NONE,TRUE);break;
case 1:DGCHECKMENUITEM(IDM_SYN_CPP,TRUE);break;
case 2:DGCHECKMENUITEM(IDM_SYN_HTML,TRUE);break;
case 3:DGCHECKMENUITEM(IDM_SYN_SQL,TRUE);break;
}
DGENABLEMENUITEM(IDM_SEARCH_NEXT,lstrlen(arFind[0].Get(0)) != 0);
DGENABLEMENUITEM(IDM_SEARCH_PREV,lstrlen(arFind[0].Get(0)) != 0);
DGENABLEMENUITEM(IDM_EDIT_INDENT,!bHexa);
DGENABLEMENUITEM(IDM_EDIT_UNINDENT,!bHexa);
DGENABLEMENUITEM(IDM_EDIT_COPYUP,!bHexa);
DGENABLEMENUITEM(IDM_EDIT_COPYDOWN,!bHexa);
DGENABLEMENUITEM(IDM_EDIT_COMMENT,lstrlen(pSi->Ae.GetParser()->GetInfo(2)) && !bHexa);
DGENABLEMENUITEM(IDM_EDIT_UNCOMMENT,lstrlen(pSi->Ae.GetParser()->GetInfo(2)) && !bHexa);
// 문서 포맷 표시
switch (pSi->Ae.GetFormat()) {
case AE_FORMAT_WIN:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_WIN,MF_BYCOMMAND);
break;
case AE_FORMAT_UNIX:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UNIX,MF_BYCOMMAND);
break;
case AE_FORMAT_MAC:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_MAC,MF_BYCOMMAND);
break;
case AE_FORMAT_UNICODE:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UNICODE,MF_BYCOMMAND);
break;
case AE_FORMAT_UNIBIG:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UNIBIG,MF_BYCOMMAND);
break;
case AE_FORMAT_UTF8:
CheckMenuRadioItem(hMenu,IDM_FILE_WIN,IDM_FILE_UTF_8,IDM_FILE_UTF_8,MF_BYCOMMAND);
break;
}
}
DGCHECKMENUITEM(IDM_VIEW_OUTPUT,bShowOutput);
DGCHECKMENUITEM(IDM_VIEW_TOOLBAR,Option.bShowToolBar);
DGCHECKMENUITEM(IDM_VIEW_STATUS,Option.bShowStatus);
DGCHECKMENUITEM(IDM_VIEW_FILE,Option.bShowFileWnd);
DGCHECKMENUITEM(IDM_VIEW_FILETAB,Option.bShowFileTab);
DGCHECKMENUITEM(IDM_EDIT_COMMODE,bComMode);
DGCHECKMENUITEM(IDM_VIEW_CLIP,Option.bShowClipWnd);
}
메뉴 항목의 사용 가능성 여부와 체크 여부를 제어하는 두 개의 매크로 함수를 정의하고 이 함수들로 메뉴 항목을 관리했다. 관리 대상과 조건만 인수로 전달하므로 읽기 쉽고 소스량도 훨씬 더 줄일 수 있다. 뿐만 아니라 삼항 조건 연산자로 인수만 선택하고 매번 함수를 호출하지 않음으로써 속도와 크기에도 유리하다. 함수 내부는 따로 분석하지 않아도 이해할 수 있을 것이다.
이 외에도 OnIdle, ApplyNow, SetSetting 등의 함수도 정리 대상이다. 더 정리할만한 곳이 어디 이 뿐이겠는가만 대충 정리하는 흉내만 내기로 한다. 이런 식으로 소스를 정리하다가는 아마 전체 소스를 다시 작성해야 할 것이다. 다음에 문서화가 끝난 후에 한번에 정리할 생각이다.
알파 5 버전까지 당근은 무수히 많은 버그들이 존재했다. 사소한 버그나 단순 오타들이 많지만 가끔씩 프로그램을 다운시키는 치명적인 버그도 있었다. 개발 자체에만 너무 치중하다 보니 좀 황당한 버그도 있었는데 어차피 개발자에게 버그는 피할 수 없는 숙명이다. 이 버그들 대부분은 앞쪽의 실습 과정을 수정하여 이미 해결해 놓았다. 마지막에 발견된 몇 가지 사소한 문제만 해결하면 된다.
파일 오픈 직후의 상태란 정보중 일부가 부정확한 문제가 있다. 특히 줄 수가 제대로 갱신되지 않는데 파일을 여는 방법에 따라 되는 경우도 있고 안되는 경우도 있다. 문서가 정렬되고 난 후에 통지 메시지를 받는가 아니면 정렬전에 통지 메시지를 받는가에 따라 달라지는데 파일을 연 후 무조건 상태란을 갱신하도록 수정한다.
BOOL OpenFileToChild(HWND hChild, TCHAR *Path)
{
....
SetStatusText(0xffff);
return TRUE;
}
일반적으로 파일이 바뀌면 영향을 받는 정보가 많으므로 상태란의 모든 파트를 전부 다시 갱신했다. 파일을 여는 동작은 그다지 자주 있는 일이 아니므로 전체를 다 바꿔도 속도상의 불이익은 거의 없다.
툴바의 저장 버튼 동작이 조금 이상한데 다른 버튼과는 달리 눌러도 쑥 들어가지 않으며 항상 위로 솟아 있다. OnIdle에서 이 버튼을 관리할 때 활성창이 있는가에 따라 사용가능성을 관리하는데 버튼을 누를 때도 상태를 강제로 변경하기 때문에 항상 사용 가능하면서 업된 상태로만 보이는 것이다. 다음과 같이 수정한다.
void OnIdle()
{
void OnIdle()
{
HWND hActive;
SInfo *pSi;
int s,e;
CApiEditText *pView;
hActive=(HWND)SendMessage(g_hMDIClient,WM_MDIGETACTIVE,0,NULL);
if (hActive) {
pSi=(SInfo *)GetWindowLongPtr(hActive,0);
pView=pSi->Ae.GetActiveView();
// 저장 버튼은 사용금지 상태일 때만 상태를 변경한다.
if ((SendMessage(hToolBar,TB_GETSTATE,IDM_FILE_SAVE,0) & TBSTATE_ENABLED)==0) {
SendMessage(hToolBar,TB_SETSTATE,IDM_FILE_SAVE,MAKELONG(TBSTATE_ENABLED,0));
}
pSi->Ae.GetSelect(s,e);
....
사용 금지 상태일 때만 사용가능하게 변경하고 그렇지 않을 경우는 저장 버튼의 상태를 별도로 조작하지 않는다. 조건만 하나만 추가하면 일반 버튼처럼 제대로 동작한다.
제품을 릴리즈하기 전에 디폴트 옵션을 적절하게 수정한다. 옵션이라는 것은 사용자가 언제든지 수정할 수 있지만 대부분의 사용자들은 옵션을 조정하지 않고 개발사가 처음 맞춰 놓은 디폴트를 그대로 사용한다. 따라서 릴리즈에 적용된 옵션은 실질적으로 사용자들이 처음 보는 제품의 모습을 반영하며 선택되지 않은 옵션은 기능의 존재를 알지도 못하는 경우가 허다하다. 그래서 상용 프로그램들은 최대한 모든 기능을 다 선택한 채로 릴리즈하여 기능의 존재를 적극적으로 알린다.
하지만 당근은 상용 프로그램이 아니므로 자신의 모든 기능을 애써 뽐낼 필요가 없다. 사용자가 불편하지 않을 정도의 기본 옵션만 선택하고 나머지는 알아서 쓰도록 기능을 감춘다. 이렇게 되면 힘들게 만든 일부 기능은 활용되지 못하는 애석함이 있지만 고급 기능을 드러내는 것보다 자연스러움을 더 중요시한다는 입장이다. 디폴트 옵션 중 일부를 조정한다.
void SOption::Init()
{
int i;
StartAction=2;
bExplorerPopup=TRUE;
....
MaxMru=3;
....
bShowFileWnd=TRUE;
....
bWrap=TRUE;
....
memset(&logfont,0,sizeof(LOGFONT));
lstrcpy(logfont.lfFaceName,"굴림");
logfont.lfHeight=10;
logfont.lfCharSet=HANGEUL_CHARSET;
logfont.lfPitchAndFamily=VARIABLE_PITCH | FF_MODERN;
....
bUseLineEnd=FALSE;
탐색기 팝업 메뉴를 기본으로 선택했는데 1.2에서는 COM 객체를 제대로 만들었으므로 모든 윈도우즈 버전에 별 문제가 없다. 디폴트가 TRUE이므로 설치 대화상자에서 옵션 비선택시 FALSE로 바꾸도록 코드를 수정한다. 설정 대화상자에서 팝업 옵션을 끌 때만 팝업 메뉴를 달지 않는다.
BOOL CALLBACK SetupDlgProc(HWND hDlg,UINT iMessage,WPARAM wParam,LPARAM lParam)
{
....
case WM_COMMAND:
switch (LOWORD(wParam))
{
case IDOK:
case IDCANCEL:
if (IsDlgButtonChecked(hDlg,IDC_IS_POPUP)==BST_CHECKED) {
RegisterPopup(TRUE);
Option.bExplorerPopup=TRUE;
} else {
Option.bExplorerPopup=FALSE;
}
MRU는 기본 20개로 늘렸는데 많아서 나쁠 건 없으므로 좀 여유있게 했다. 파일창은 기본적으로 표시하고 글꼴은 굴림 10포인트로 맞추었다. 시스템 글꼴은 별로 예쁘지도 않고 좋지 않아 가장 무난한 글꼴을 선택했는데 이렇게 글꼴을 고정해 버리면 국제화에는 불리하다. ApiEdit에 글꼴을 적용하는 SetSetting 함수를 수정한다.
void SetSetting(CApiEdit &Ae)
{
....
if (Option.logfont.lfHeight != 0) {
tFont=Option.logfont;
hdc=GetDC(NULL);
tFont.lfHeight=Option.logfont.lfHeight*GetDeviceCaps(hdc,LOGPIXELSY)/72;
tFont.lfWidth=0;
ReleaseDC(NULL,hdc);
Ae.SetFont(&tFont);
}
높이가 0이 아니면, 즉 시스템 폰트가 아니면 무조건 폰트를 적용해야 한다. 자동 개행은 아무래도 처음부터 적용하는 것이 좋을 것 같고 bUseLineEnd는 사용하지 않는다. 아무래도 부자연스러워 보인다. 이 두 옵션은 컨트롤의 디폴트도 수정한다.
void CApiEditText::SetDefaultSetting()
{
if (pLine) {
SetLineRatio(120);
SetWrap(2);
SetTabWidth(4);
SetShowState(SHOWMARGIN,TRUE);
} else {
LineRatio=120;
nWrap=2;
TabWidth=4;
MarginWidth=25;
}
CApiEdit::CApiEdit()
{
....
bUseLineEnd=FALSE;
C 구문 분석기의 디폴트 색상도 조금 수정한다. 당근 1.0은 숫자를 파란색으로 키워드를 빨간색으로 표시하는데 눈에 더 잘 띄는 파란색을 빈도가 높은 키워드 표시에 사용하는 것이 더 좋을 것 같다. 물론 사용자가 언제든지 편집할 수 있는 대상이기는 하지만 디폴트를 무난하게 설정하여 편집하지 않고도 바로 쓸 수 있는 것이 더 좋다. CParseCpp 클래스 생성자의 초기 색상만 다음과 같이 수정하면 된다.
CParseCpp::CParseCpp()
{
....
lstrcpy(arStyle[4].name,"숫자");
arStyle[4].fore=RGB(255,0,0);
lstrcpy(arStyle[5].name,"키워드");
arStyle[5].fore=RGB(0,0,255);
lstrcpy(arStyle[6].name,"전처리기");
arStyle[6].fore=RGB(255,0,255);
}
최초 실행시 파일창, 상용구 창이 다 보이는데 아무 것도 표시되지 않는 것은 혼란을 줄 수 있다. 특히 상용구 창은 처음 실행하면 멀건 흰 윈도우만 보여, 저게 트리뷰인지, 리스트 박스인지도 구분이 안되며 용도를 짐작하기도 어렵다. 그래서 최초 실행시 샘플 파일을 연다. OnTimer에 다음 코드를 작성한다.
void OnTimer(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
....
TCHAR Drive[_MAX_DRIVE];
TCHAR Dir[_MAX_DIR];
switch (wParam) {
....
case 100:
....
// 처음 실행할 때 샘플 프로젝트와 상용구를 연다
if (SHRegReadInt(SHCU,KEY"Project","Num",101092)==101092) {
SHRegReadString(SHCU,KEY"Setting","InstPath","",Path,MAX_PATH);
_splitpath(Path,Drive,Dir,NULL,NULL);
wsprintf(Path,"%s%sSample.dgp",Drive,Dir);
if (_access(Path,0)==0) {
LoadProject(Path,FALSE);
}
wsprintf(Path,"%s%sSample.dgc",Drive,Dir);
if (_access(Path,0)==0) {
LoadClipFile(Path,FALSE);
}
}
Option.bMaxFirstChild=bOldMaxFirstChild;
SHRegReadString(SHCU,KEY"Setting","LastFolder","",Path,MAX_PATH);
GotoFolderInTree(Path);
break;
}
}
처음 실행했으면 레지스트리에는 InstPath 키만 있고 아직 아무 키도 없다. Project 서브키의 Num을 읽어 보되 디폴트를 101092로 주고 이 값이 그대로 리턴되면 처음 실행한 것으로 판단할 수 있다. 처음 실행했으면 설치 폴더에 있는 Sample.dgp, Sample.dgc를 연다. 이 기능이 제대로 동작하려면 배포할 때 Dangeun.exe와 샘플 파일들을 같이 배포해야 한다. 물론 필수 파일은 아니다. 만약 누군가가 Dangeun.exe만 복사해서 실행했더라도 샘플 파일이 열리지 않을 뿐이지 동작에는 아무 문제가 없어야 한다. 파일의 존재 여부를 먼저 조사하여 에러 메시지조차도 출력하지 않았다. 없으면 없는대로 그냥 조용히 실행되어야 한다.
마지막으로 정확한 버전을 표시한다. 프로그램의 버전은 여러 군데 표시되는데 당근의 경우 프로그램 소개 대화상자와 메인 윈도우에 표시된다. About 대화상자에 현재 알파 5라고 되어 있는데 베타 1로 수정한다. 그리고 메인 윈도우의 타이틀 바의 문자열도 다음과 같이 수정한다.
int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance
,LPSTR lpszCmdParam,int nCmdShow)
{
...
hWnd=CreateWindow(lpszClass,"당근 Beta1",WS_OVERLAPPEDWINDOW | WS_VISIBLE |
WS_CLIPCHILDREN,
CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,CW_USEDEFAULT,
NULL,(HMENU)NULL,hInstance,NULL);
여기서 릴리즈하는 버전은 베타 1이다. 그 이전에도 알파1, 2, 3, 4, 5를 개발했었는데 알파 버전의 수정 사항들은 모두 앞쪽 실습 과정에 미리 반영해 두었다. 개발자 내부 버전이므로 아직까지 버그가 많이 남아 있는데 잠시 후 연이어 베타 2를 작성할 것이다. 베타 버전부터는 이미 완료된 실습 문서는 그대로 유지하고 따로 버그를 수정할 것이다. 프로젝트 전체를 풀 빌드하면 릴리즈가 완료된다.
VC 6.0으로 컴파일하면 612K, VC 8.0으로 컴파일하면 632K의 크기로 빌드된다. DgCmd.dll과 샘플 비트맵 등이 포함되어 실행 파일 크기가 다소 크다. 변경된 초기 옵션 적용을 위해서는 설치 해제 후 다시 실행해야 한다.