4.편집 히스토리

가.그룹 헤더

당근의 취소, 재실행 기능은 메모리 용량까지 무한 단계의 편집 과정을 저장할 수 있다는 면에서 상당히 우수한 편이다. 그런데 취소, 재실행을 할 때 한 단계씩만 취소, 재실행할 수 있으므로 한참 이전의 단계로 돌아가고 싶으면 Ctrl+Z를 계속 누르고 있어야 하므로 다소 불편한 면이 있다. 지금까지 편집했던 과정의 목록을 보여주고 지정한 지점까지 한꺼번에 취소할 수 있다면 더 편리할 것이다. 비주얼 스튜디오와 워드에 이미 이 기능이 작성되어 있는데 이 기능과 똑같이 만들어 보자.

이 기능은 한꺼번에 편집 동작을 취소할 수 있다는 면에서 실용성이 있을 뿐만 아니라 편집 기록을 살펴 보는 용도로도 가치가 있다. 목록을 펼쳐 보면 어떤 동작을 어떤 순서대로 실행했는지를 일목 요연하게 알 수 있다. 삽입, 삭제, 이동 등의 동작에 대해 이름을 붙이고 삽입, 삭제 대상까지도 표시하면 편집 동작을 요약적으로 표현할 수 있다.

그룹 동작은 세부적으로 수많은 삽입, 삭제, 이동으로 이루어지는데 하나의 편집 동작을 위한 그룹이므로 목록에도 하나로 기록하는 것이 더 좋다. 이때 그룹 동작에 대한 설명을 어떻게 표시할 것인가가 문제인데 그룹 동작에 대해서도 설명을 붙일 수 있어야 한다. 현재 편집 그룹은 StartUndoGroup 함수로 시작되며 틱 카운트와 그룹 선두 레코드의 번호를 조합한 그룹 ID로 그룹에 속한 레코드를 구분할 뿐 별도의 설명은 작성되지 않는다. 그래서 그룹에 대한 설명 레코드를 작성하기 위해 UR_GROUP이라는 레코드 타입을 추가한다.

enum { UR_NONE, UR_INSERT, UR_DELETE, UR_MOVE, UR_GROUP };

이 레코드는 실제 편집 동작을 기록하지는 않지만 그룹에 대한 설명을 붙이는 용도로 사용된다. pos나 len 등은 사용하지 않으며 data에 문자열 포맷으로 편집 그룹에 대한 간략한 설명을 저장할 것이다. 예를 들어 블록 들여쓰기 동작을 위한 편집을 한다면 "블록 들여쓰기"라는 문자열을 가지는 UR_GROUP 레코드를 먼저 작성하고 이 레코드 뒤에 편집 동작의 그룹이 따라오는 식이다. 그룹을 시작하는 함수를 다음과 같이 수정한다.

void CApiEdit::StartUndoGroup(int id, TCHAR *desc/*=NULL*/)

{

// 항상 새로운 레코드에서 시작하며 병합하지 않는다.

if (CanRedo()) {

ClearRedo();

} else {

if (pUR[nowur].action != UR_NONE) {

NextRecord();

}

}

// 새 그룹이 시작되면 UR_GROUP 레코드를 작성한다. 중첩 그룹은 제외한다.

if (URnest==0) {

URtick=((nowur << 16) | (GetTickCount() & 0xffff));

// 설명은 desc에 작성하고 그룹 id는 pos에 기록한다.

if (desc) {

AllocURData(nowur,lstrlen(desc)+1,0);

lstrcpy(pUR[nowur].data,desc);

} else {

AllocURData(nowur,sizeof(int)*2,0);

lstrcpy(pUR[nowur].data,"");

}

pUR[nowur].action=UR_GROUP;

pUR[nowur].pos=id;

pUR[nowur].tick=URtick;

}

URnest++;

}

그룹 헤더는 항상 새로운 레코드에서 시작한다. 즉, 그룹은 그룹 이전의 레코드와 조건이 맞아도 병합하지 않는다. 1.0의 병합 알고리즘에 치명적인 문제는 아니지만 약간의 버그가 있었는데 StartUndoGroup이 새 레코드 분할을 하지 않기 때문에 그룹과 안그룹 레코드가 병합되는 문제점이 있다. 예를 들어 abcdef가 입력되어 있을 때 d자리에서 BS세번 눌러 abc지우고 def를 블록으로 선택한 후 ghi로 대체하면 다음과 같이 기록된다.

문서	동작	레코드
abcdef	abc지움	abc 삭제
def	def 선택 후 ghi삽입	abc 삭제와 def 삭제 병합 ghi 삽입
ghi

def 삭제가 직전의 abc 삭제와 병합되어 버리기 때문에 ghi 삽입이 선택 대체 그룹을 구성하지 못하는 것이다. def 삭제와 ghi 삽입이 한 동작이므로 이 둘이 그룹이 되어야 하며 abc 삭제와 def 삭제는 조건이 맞더라도 한 그룹이 되어서는 안된다. 이런 문제를 해결하기 위해 앞쪽 레코드에 편집 동작이 기록되어 있으면 무조건 NextRecord로 다음 레코드로 이동했다.

그룹이 시작되면 UR_GROUP 그룹 레코드를 작성한다. 인수로 그룹의 동작을 설명하는 정수형의 id와 추가 설명 문자열을 전달받아 id는 취소 레코드의 pos에 기록하고 설명은 data에 메모리를 할당하여 기록한다. 단, 이 그룹 레코드는 그룹의 헤더일 경우만 작성한다. 다른 그룹에 중첩된 그룹은 목록에 나타나지 않기 때문에 설명을 따로 붙일 필요가 없다. 그룹에 속한 그룹은 더 이상 그룹이 아니며 그룹을 구성하는 구성원일 뿐이다.

그룹을 시작하는 StartUndoGroup 함수의 원형이 수정되었으므로 이 함수를 호출하는 모든 부분에서 그룹을 시작할 때 id와 필요할 경우 설명 문자열을 제공해야 한다. StartUndoGroup에 인수만 추가하면 된다. 대부분 ApiEditText.cpp에 있다.

위치	설명
OnChar OnImeComposition InsertText	pFrame->StartUndoGroup(1);
IDM_AE_PASTE	pFrame->StartUndoGroup(2);
ChangeCase	pFrame->StartUndoGroup(3);
RemoveExtraSpace	pFrame->StartUndoGroup(4);
BlockIndent	pFrame->StartUndoGroup(5);
Dangeun.cpp의 OnUser2	pSi->Ae.StartUndoGroup(6);
CApiEditHexa::OnChar	pFrame->StartUndoGroup(7);

다음 세 함수는 좀 더 자세한 설명을 붙이기 위해 구조가 약간 바뀌기도 한다. 예를 들여 블록 들여쓰기의 경우 들여쓰기인지 내어쓰기인지를 구분해야 하며 InsertComment 함수의 경우 주석화와 주석 해제를 동시에 하고 있으므로 전달된 인수에 따라 설명을 달리해야 한다.

void CApiEditText::ProcessIndent(TCHAR ch)

{

TCHAR szIndent[4096];

int toff;

int tlen;

BOOL bAllSpace;

int nTab;

if (ch == '\r') {

if (IsPrevParaBlockOpen(off)) {

MakeIndentString(1,szIndent,4096);

pFrame->StartUndoGroup(9);

} else {

lstrcpy(szIndent,"");

pFrame->StartUndoGroup(8);

}

pFrame->StartUndoGroup();

....

if (ch!='\r' && tlen && off >= tlen) {

....

pFrame->StartUndoGroup(10);

int CApiEditText::ReplaceText(int nPos, TCHAR *what, DWORD dwFlag, TCHAR *to)

{

TCHAR szDesc[1024];

....

wsprintf(szDesc," (%s -> %s)",what,to);

pFrame->StartUndoGroup(11,szDesc);

void CApiEditText::ConvertSpaceTab(BOOL bToSpace)

{

....

if (bToSpace) {

....

pFrame->StartUndoGroup(12);

} else {

....

pFrame->StartUndoGroup(13);

}

pFrame->StartUndoGroup();

void CApiEditText::InsertComment(BOOL bUnComment)

{

if (!bUnComment) {

....

pFrame->StartUndoGroup(14);

} else {

....

pFrame->StartUndoGroup(15);

}

pFrame->StartUndoGroup();

그룹을 구성할 때마다 취소 레코드에 그룹 설명을 위한 레코드를 작성하므로 메모리는 조금 더 쓰게 될 것이다. 각 그룹 동작이 구체적으로 어떤 동작인지는 별도의 문자열 배열을 작성한다. 다음 배열을 Dangeun.cpp의 선두에 정의한다.

TCHAR arGroupDesc[50][32]={"",

"선택 대체",

"선택 대체 붙여 넣기",

"대소문자 변경",

"여분 공백 제거",

"블록 들여쓰기", // 5

"모두 바꾸기",

"이진 바이트 편집",

"자동 들여쓰기",

"문법 들여쓰기",

"문법 내어쓰기", // 10

"바꾸기",

"탭을 공백으로",

"공백을 탭으로",

"주석으로",

"주석 제거", // 15

"열 삭제",

"열 붙여넣기",

"열 복사",

"열 이동",

"열 대소문자 변경", // 20

"매크로 실행",

"상용구 삽입",

"자동 상용구 삽입",

"삭제-스마트 공백",

"붙여 넣기", // 25

"복사",

"이동",

"문단 병합",

"문단 분할",

"문단 수평 정렬", // 30

"문단 크기순 정렬",

"문단 빈줄 조정",

};

지금 당장 정의되지 않은 그룹 동작에 대한 설명도 미리 작성해 놓았다. 그룹 동작이 더 늘어나면 이 배열의 크기와 초기화 문자열도 같이 늘어날 것이다. 취소 레코드의 action이 UR_GROUP이고 pos가 5이면 블록 들여쓰기 동작에 대한 그룹임을 알 수 있다. 그룹 동작에 대해 정수형으로 id를 붙이고 호스트가 id에 대한 설명 문자열을 제공하는 이유는 다국어 버전을 쉽게 만들기 위해서이다.

호스트는 문자열 리소스를 바꾸면 다른 언어를 쓸 수 있다. 그러나 컨트롤은 리소스를 가지지 않기 때문에 다른 언어를 지원하려면 무척 번거로와진다. 그래서 ApiEdit는 그룹 동작에 대한 설명을 직접 문자열로 달지 않고 일련 번호로 정의하기만 한다. 현재까지 ApiEdit의 소스에서 문자열을 직접 사용한 경우는 팝업 메뉴의 "잘라내기", "복사" 같은 메뉴 캡션밖에 없다. 이 문자열도 물론 나중에는 다른 방식으로 구하도록 바꾸어야 한다. 컨트롤이 직접 문자열을 다루는 것은 좋지 않다.

그룹 시작만 해 놓고 실제 레코드를 기록하지 않는 경우가 있다. 예를 들어 자동 들여쓰기의 경우 그룹 시작은 했지만 자동 들여쓰기 할 내용이 없으면 실제 레코드가 기록되지 않는다. 모두 바꾸기의 경우 일단 그룹을 시작하지만 찾는 내용이 없으면 그룹 헤더만 있고 본체는 없을 것이다. 나홀로 그룹은 사실 존재 가치가 없지만 코드를 간단하게 하기 위해서는 불가피하게 일시적으로 생성될 수밖에 없다. 그룹을 시작하는 시점에서 실제 편집 여부를 판단하기가 대단히 어렵다. 그래서 일단 나홀로 그룹을 기록해 놓고 그룹을 끝낼 때 이 그룹이 실제 편집 레코드를 가지고 있는지 점검해 보고 빈 레코드이면 삭제한다.

void CApiEdit::EndUndoGroup()

{

URnest--;

if (URnest==0) {

if (pUR[nowur].action == UR_GROUP) {

pUR[nowur].action=UR_NONE;

}

URtick=0;

}

}

그룹을 끝낼 때 nowur자리가 그룹 헤더라면 빈 그룹이므로 이 레코드의 action을 UR_NONE으로 만들어 다음 레코드 작성시 재사용한다. 할당해 놓은 메모리나 pos, tick값은 그대로 두어도 어차피 다음에 새로운 값으로 대입되므로 상관없다. 그룹을 끝낼 때 NextRecord는 호출하지 않는데 바로 다음번 레코드가 그룹의 끝 레코드와 병합될 수 있기 때문이다. 예를 들어 abc를 선택해 놓고 def로 대체할 때 abc 삭제와 d입력이 일단 그룹으로 작성되며 이어지는 ef 삽입이 d삽입과 병합되어야 abc 삭제, def 삽입이 한 그룹이 될 수 있다.

나.그룹 관리 함수

다음 함수들은 편집 그룹을 관리하는 함수들이며 다음 항의 편집 기록창에서 사용한다. FindGroupEnd는 그룹의 마지막 레코드를 찾는 유틸리티 함수이다. 틱값이 다른 최초의 레코드를 찾은 후 바로 직전의 레코드 번호를 취하면 여기가 그룹의 끝이다.

int CApiEdit::FindGroupEnd(int idx)

{

int i;

for (i=idx+1;pUR[i].tick == pUR[idx].tick;i++);

return i-1;

}

void CApiEdit::MultiUndo(int idx)

{

for (;;) {

if (CanUndo()) {

Undo();

} else {

break;

}

if (nowur <= idx) {

break;

}

}

}

void CApiEdit::MultiRedo(int idx)

{

for (;;) {

if (CanRedo()) {

Redo();

} else {

break;

}

if (nowur > idx) {

break;

}

}

}

MultiUndo, MutiRedo는 인수로 전달받은 idx번까지 한꺼번에 Undo, Redo한다. idx에 이를 때까지 Undo, Redo를 계속 호출하는 간단한 구조로 되어 있으며 그만둘 시점을 판단하는 부등호에만 주의하면 된다. MuitiUndo는 idx보다 크지 않을 때 탈출하므로 <=로 비교, MultiRedo는 idx보다 클 때 탈출하므로 >로 비교한다.

이 차이는 Undo와 Redo 함수의 구조 차이에서 기인하며 더 근본적으로는 nowur이 어디를 가리키고 있는가의 정의에 의해 결정된 것이다. Undo는 탈출 점검을 한 후 nowur--로 다음 루프를 돌기 때문에 취소후 그 자리에 머문다. 반면 Redo는 무조건 NextRecord호출을 먼저하고 탈출 점검을 하므로 재실행 후 다음 레코드로 이동해 있게 된다.

그래서 nowur과 idx가 같아진 상황에 대한 처리가 달라지는 것이다. MultiUndo는 idx까지 이미 취소되었으므로 이때 탈출한다. MultiRedo는 아직 idx까지 재실행한 것이 아니므로 한번 더 Redo를 호출해야 한다. 이렇게 설명을 읽으면 정말 복잡해 보이지만 실제로 문제를 풀어 보면 별 것도 아니다. 처음에 대충 만들어 놓고 디버거로 돌려 보면 어떤 연산자로 비교를 해야 할지 쉽게 결정할 수 있다.

그룹 헤더 레코드가 추가되었지만 Undo, Redo 등 취소 레코드를 관리 및 사용하는 함수들은 수정할 필요가 없다. Undo, Redo 함수는 action에 따라 적절한 동작을 하는데 action의 switch 문에 case UR_GROUP에 대한 처리가 없기 때문에 자연히 무시된다.

다.편집 기록창

편집 기록창 표시를 위해 툴바의 취소, 재실행 버튼의 스타일을 드롭 다운으로 변경해 놓았다. 이 버튼을 누르면 편집 과정을 표시하는 작은 대화상자를 열 것이다. 드롭 다운 툴바를 열면 WM_NOTIFY 통지 메시지가 전달되는데 이 메시지를 받았을 때 편집 기록을 보여준다.

static HWND hEdRecDlg;

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

{

....

switch (hdr->code) {

case TTN_GETDISPINFO:

....

case TBN_DROPDOWN:

hEdRecDlg=CreateDialogParam(g_hInst, MAKEINTRESOURCE(IDD_EDITRECORD),

hWnd, (DLGPROC)EditRecordProc,((NMTOOLBAR *)lParam)->iItem);

break;

}

}

편집 기록을 표시하는 작은 팝업 대화상자를 모델리스로 만든다. 포커스를 잃으면 즉시 사라져야 하므로 모델리스로 만들었으며 메인 메시지 루프에서 모델리스 대화상자로 메시지를 보내야 한다.

int APIENTRY WinMain(HINSTANCE hInstance,HINSTANCE hPrevInstance

,LPSTR lpszCmdParam,int nCmdShow)

{

....

if ((!IsWindow(g_FindDlg) || !IsDialogMessage(g_FindDlg,&Message)) &&

(!IsWindow(hEdRecDlg) || !IsDialogMessage(hEdRecDlg,&Message)) ) {

if (!TranslateMDISysAccel(g_hMDIClient, &Message)) {

if (!TranslateAccelerator(hWnd,hAccel,&Message)) {

TranslateMessage(&Message);

DispatchMessage(&Message);

}

}

}

편집 기록 중의 탭이나 개행 코드 등을 그대로 출력하면 그래픽 문자로 표시되므로 이 제어 코드를 눈에 보이는 다른 문자로 대체해서 표시하는 것이 더 보기에 좋다. 다음 함수를 Util.cpp에 작성한다.

// 제어코드를 읽을 수 있는 문자로 변환한다.

void ReplaceCtrlString(TCHAR *src, int slen, TCHAR *dest, int dlen)

{

TCHAR *s,*d;

TCHAR *dest2;

s=src;

if (dest==NULL) {

d=dest2=(TCHAR *)malloc(1024);

dlen=1024;

} else {

d=dest;

}

memset(d,0,dlen);

for (;*s;d++, s++) {

if (s-src >= slen) {

break;

}

if ((dest && d-dest >= dlen-1) || (dest==NULL && d-dest2 >= dlen-1)) {

break;

}

if (*s == '\r' && s-src+1 < slen && s[1] == '\n') {

lstrcat(d,"[개행]");

d+=5;

s++;

} else if (*s == '\t') {

lstrcat(d,"[탭]");

d+=3;

} else {

if (IsDBCSLeadByte(*s)) {

*d++=*s++;

*d=*s;

} else {

if (*s >= 0x20 && *s <= 0x7e) {

*d=*s;

} else {

*d='.';

}

}

}

}

if (dest==NULL) {

lstrcpy(src,dest2);

free(dest2);

}

}

ReplaceCtrlString 함수는 탭, 개행 코드를 읽을 수 있는 문자열로 변경하며 그 외의 인쇄할 수 없는 제어 코드는 .으로 표시한다. 이진 파일을 다룰 수 있기 때문에 임의의 문자 코드가 올 수 있으므로 모든 코드에 대해 눈에 보이는 문자열로 변환해야 한다. src를 변환하여 dest에 복사하되 dest가 NULL이면 임시 버퍼를 할당하여 변환하고 그 결과를 다시 src에 복사한다. 이때 src는 변환 후의 문자열을 저장할 수 있을만큼 충분한 길이를 가져야 한다. 호출하는 측에서는 src와 dest를 동시에 전달하여 src를 유지한 채로 변환 결과를 받을 수도 있고 src만 전달하여 변환 결과를 src에 다시 채우게 할 수 있다.

다음은 편집 기록 대화상자 프로시저를 작성한다. 이 대화상자는 취소 및 재실행 버튼 둘 다에 대해 동작하는데 lParam으로 툴바 버튼의 ID를 전달받아 눌러진 버튼에 따라 목록을 다르게 작성한다. 어차피 둘 다 취소 레코드의 목록을 표시하므로 출력 과정은 거의 비슷할 것이다.

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

{

static BOOL bUndo;

static HWND hList;

RECT rt;

LVCOLUMN COL;

SInfo *pSi;

HWND hActive;

int idx, count, Inc, idx2;

UndoRecord *pUR;

LVITEM LI;

TCHAR szAct[12], szCon[1024];

switch(iMessage) {

case WM_INITDIALOG:

if (lParam == IDM_EDIT_UNDO) {

bUndo=TRUE;

Inc=-1;

SetDlgItemText(hDlg,IDC_MULTIUR,"선택 동작까지 취소");

} else {

bUndo=FALSE;

Inc=1;

SetDlgItemText(hDlg,IDC_MULTIUR,"선택 동작까지 재실행");

}

SendMessage(hToolBar,TB_GETITEMRECT,bUndo ? 8:9,(LPARAM)&rt);

rt.top=rt.bottom+2;

ClientToScreen(g_hFrameWnd,(LPPOINT)&rt);

SetWindowPos(hDlg,HWND_NOTOPMOST,rt.left,

rt.top,0,0,SWP_NOSIZE);

hList=GetDlgItem(hDlg,IDC_UNDOLIST);

COL.mask=LVCF_FMT | LVCF_WIDTH | LVCF_TEXT | LVCF_SUBITEM;

COL.fmt=LVCFMT_LEFT;

COL.cx=40;

COL.pszText="동작";

COL.iSubItem=0;

ListView_InsertColumn(hList,0,&COL);

COL.cx=145;

COL.pszText="내용";

COL.iSubItem=1;

ListView_InsertColumn(hList,1,&COL);

ListView_SetExtendedListViewStyle(hList, LVS_EX_FULLROWSELECT);

hActive=(HWND)SendMessage(g_hMDIClient,WM_MDIGETACTIVE,0,NULL);

pSi=(SInfo *)GetWindowLong(hActive,0);

for (idx=pSi->Ae.nowur, count=0;;idx+=Inc) {

pUR=&pSi->Ae.pUR[idx];

if (bUndo) {

if (pUR->action == UR_NONE || pUR->status == UR_CANCELED)

continue;

} else {

if (pUR->action == UR_NONE)

break;

}

if (bUndo && pUR->action != UR_GROUP && pUR->tick) {

for (;idx >= 0;idx--) {

if (pSi->Ae.pUR[idx].action==UR_GROUP && pSi->Ae.pUR[idx].tick==pUR->tick) {

break;

}

}

if (idx < 0) {

break;

}

switch (pSi->Ae.pUR[idx].pos) {

case 8:

case 9:

for (idx2=idx;;idx2++) {

if (pSi->Ae.pUR[idx2].action==UR_INSERT)

break;

}

lstrcpy(szAct,"삽입");

ReplaceCtrlString(pSi->Ae.pUR[idx2].data,pSi->Ae.pUR[idx2].len,szCon,1024);

break;

default:

lstrcpy(szAct,"그룹");

lstrcpy(szCon,arGroupDesc[pSi->Ae.pUR[idx].pos]);

if (pSi->Ae.pUR[idx].data) {

lstrcat(szCon,pSi->Ae.pUR[idx].data);

}

break;

}

} else if (bUndo==FALSE && pUR->action == UR_GROUP) {

switch (pSi->Ae.pUR[idx].pos) {

case 8:

case 9:

for (idx2=idx;;idx2++) {

if (pSi->Ae.pUR[idx2].action==UR_INSERT)

break;

}

lstrcpy(szAct,"삽입");

ReplaceCtrlString(pSi->Ae.pUR[idx2].data,pSi->Ae.pUR[idx2].len,szCon,1024);

break;

default:

lstrcpy(szAct,"그룹");

lstrcpy(szCon,arGroupDesc[pUR->pos]);

if (pUR->data) {

lstrcat(szCon,pUR->data);

}

break;

}

idx=pSi->Ae.FindGroupEnd(idx);

} else {

switch (pUR->action) {

case UR_INSERT:

lstrcpy(szAct,"삽입");

ReplaceCtrlString(pUR->data,pUR->len,szCon,1024);

break;

case UR_DELETE:

lstrcpy(szAct,"삭제");

ReplaceCtrlString(pUR->data,pUR->len,szCon,1024);

break;

case UR_MOVE:

lstrcpy(szAct,"이동");

wsprintf(szCon,"%d -> %d(%d바이트)",pUR->pos,pUR->dest[0],pUR->dest[1]);

break;

}

}

LI.mask=LVIF_TEXT | LVIF_PARAM;

LI.iItem=count;

LI.iSubItem=0;

LI.lParam=idx;

LI.pszText=szAct;

ListView_InsertItem(hList,&LI);

ListView_SetItemText(hList,count,1,szCon);

if ((bUndo && idx == 0) || count == 200) {

break;

}

count++;

}

SetFocus(hList);

return FALSE;

case WM_ACTIVATE:

if (LOWORD(wParam) == WA_INACTIVE) {

PostMessage(hDlg,WM_COMMAND,MAKEWPARAM(IDCANCEL,0),0);

return TRUE;

}

break;

case WM_COMMAND:

switch (LOWORD(wParam)) {

case IDC_MULTIUR:

idx=ListView_GetNextItem(hList,-1,LVNI_ALL | LVNI_SELECTED);

if (idx != -1) {

LI.mask=LVIF_PARAM;

LI.iItem=idx;

ListView_GetItem(hList,&LI);

PostMessage(g_hFrameWnd,WM_USER+3,(WPARAM)bUndo,(LPARAM)LI.lParam);

}

case IDCANCEL:

DestroyWindow(hDlg);

return FALSE;

}

return FALSE;

case WM_NOTIFY:

LPNMHDR hdr;

hdr=(LPNMHDR)lParam;

if (hdr->hwndFrom == hList) {

switch (hdr->code) {

case NM_DBLCLK:

PostMessage(hDlg,WM_COMMAND,MAKEWPARAM(IDC_MULTIUR,0),0);

return TRUE;

}

}

break;

}

return FALSE;

}

대화상자가 열릴 때 lParam으로 어떤 툴 버튼이 눌러졌는지 ID를 전달받는데 이 값으로부터 취소 기록인지, 재실행 기록인지를 판단하여 bUndo 스태틱 변수에 저장한다. WM_INITDIALOG에서 리스트 뷰 컨트롤을 초기화하고 편집 기록을 리스트 뷰에 출력한다. nowur부터 순서대로 취소 레코드를 읽어 그 내용을 리스트 뷰에 등록했다.

목록을 채우는 방법은 bUndo에 따라 달라진다. 일단 nowur에서 목록을 작성할 방향이 달라지는데 이 방향은 Inc변수가 기억한다. 목록을 채우는 for 루프는 nowur에서 시작해서 Inc 방향으로 증감하면서 아래 위로 이동하며 발견되는 레코드를 리스트 뷰에 채운다. 취소 목록인 경우는 이미 취소된 레코드나 아직 작성되지 않은 레코드는 취소 대상이 아니므로 취소 가능한 목록을 만날 때까지 계속 루프의 선두로 보내기만 한다. 재실행 목록인 경우 UR_NONE을 만나면 목록의 끝이므로 이때 루프를 종료한다.

그룹 레코드를 처리하는 방법도 상당히 다르다. 취소 목록의 경우 그룹 요소가 나타나면 일단 그룹 헤더를 찾아 헤더의 설명을 취한다. 단, 취소 레코드 개수 관리 기능에 의해 요소만 남고 헤더는 잘려 나간 경우가 있을 수 있는데 이때는 목록 작성을 끝낸다. 그룹 헤더의 id가 8, 9번 즉 들여쓰기인 경우는 들여쓰기 후에 삽입된 문자열과 함께 삽입으로 처리하고 나머지 그룹은 "그룹" 동작의 설명 문자열을 내용으로 취한다. 재실행 목록의 경우 그룹 헤더를 먼저 만나는데 이때는 헤더의 설명을 취하고 그룹의 끝으로 이동한다. 다음 루프에서 idx를 1증가시키므로 정확하게 그룹 다음 레코드부터 목록을 작성하게 될 것이다.

그룹이 아닌 삽입, 삭제, 이동 레코드에 대한 목록 작성은 아주 직관적이다. 설명을 각각 "삽입", "삭제","이동"으로 작성하고 삽입, 삭제된 문자열을 ReplaceCtrlString으로 제어 코드를 처리한 후 리스트 뷰에 추가하고 이동인 경우는 어디서부터 어디까지 몇 바이트를 이동했는지를 표시한다. 리스트 뷰에 항목을 추가한 후 루프 끝 점검을 하는데 취소 목록에서 레코드의 처음을 만났거나 최대 개수가 200개를 넘으면 루프를 종료한다. 최대 200개까지의 동작을 한꺼번에 취소할 수 있다는 뜻이다.

사용자는 편집 기록 대화상자에서 편집 기록을 살펴 보고 어디까지 취소 또는 재실행을 할 것인가를 선택할 수 있다. 사용자가 목록을 더블 클릭하거나 취소 버튼을 누르면 WM_USER+3 메시지를 부모 윈도우의 메시지 큐에 붙인다. 이때 wParam으로는 취소인지 재실행인지를 알리는 bUndo의 값이 전달되고 lParam으로는 리스트뷰에서 선택된 레코드의 인덱스를 전달한다. SendMessage로 메시지를 보내지 않고 PostMessage로 붙이는 이유는 일단 이 대화상자를 닫은 후에 취소 및 재실행을 해야 하기 때문이다. 그래서 case IDC_MULTIUR: 다음에는 break가 없다.

편집 기록 대화상자는 모델리스로 열리는데 사용자가 반드시 취소 및 재실행을 하기 위해서만 여는 것은 아니다. 때로는 어떤 편집을 했는지 확인만 하기 위해 열 수도 있으므로 자신이 비활성화되면 즉시 창을 닫아야 한다. 그래서 WM_ACTIVATE에서 비활성화될 때 자신에게 IDCANCEL 메시지를 처리하여 대화상자를 닫는다. WM_ACTIVATE에서 바로 DestroyWindow로 자기 자신을 파괴해 버리면 메인 윈도우가 활성화되지 않으므로 반드시 IDCANCEL 을 큐에 붙여 정상적인 과정으로 파괴해야 한다. 메인 윈도우는 이 대화상자가 보내는 WM_USER+3 메시지를 처리한다.

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

{

switch(iMessage) {

....

case WM_USER+3:OnUser3(hWnd,wParam,lParam);return 0;

}

return(DefFrameProc(hWnd,g_hMDIClient,iMessage,wParam,lParam));

}

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

{

SInfo *pSi;

HWND hActive;

hActive=(HWND)SendMessage(g_hMDIClient, WM_MDIGETACTIVE,0,NULL);

if (hActive) {

pSi=(SInfo *)GetWindowLong(hActive,0);

if (wParam == TRUE) {

pSi->Ae.MultiUndo(lParam);

} else {

pSi->Ae.MultiRedo(lParam);

}

}

}

wParam값에 따라 MultiUndo 또는 MultiRedo 함수를 호출한다. 취소 및 재실행 대상 레코드의 인덱스는 lParam으로 전달되므로 이 값을 인수로 그대로 전달하면 된다.