2.분할 관리

가. 분할 크기 조정

스플릿 박스를 뷰가 가지고 있기 때문에 최초의 분할 명령은 뷰가 받지만 일단 두 개 이상의 뷰로 분할되면 이때부터 분할창 관리는 프레임이 한다. 분할된 뷰 사이에 약간의 여백이 드러나는데 이 여백은 프레임의 작업영역이며 스플릿 바(Split Bar)라고 불린다. 여기서의 마우스 입력은 분할 비율 조정이나 분할 해제 명령을 받아들이는 유저 인터페이스가 되는데 여기를 드래그하여 분할 비율을 조정하고 작업영역 상단이나 하단으로 드래그하면 분할을 해제한다. 스플릿 바에서 분할 비율을 조정할 수 있다는 것을 직관적으로 보여주기 위해 프레임은 이 영역에 마우스가 있을 때 커서 모양을 적당히 바꿔야 한다. OnSetCursor에 다음 코드를 작성한다.

BOOL CApiEdit::OnSetCursor(HWND hWnd, HWND hwndCursor, UINT codeHitTest, UINT msg)

{

RECT crt,rt;

POINT pt;

int width,height;

BOOL bVert=FALSE,bHorz=FALSE;

if ((VertRatio || HorzRatio) && codeHitTest==HTCLIENT) {

GetClientRect(hWnd,&crt);

GetCursorPos(&pt);

ScreenToClient(hWnd,&pt);

// 수직 스플릿 바 위

if (VertRatio) {

height=(crt.bottom-VGAP)*VertRatio/10000;

SetRect(&rt,crt.left,height,crt.right,height+VGAP);

if (PtInRect(&rt,pt)) {

bVert=TRUE;

}

}

// 수평 스클릿 바 위

if (HorzRatio) {

width=(crt.right-VGAP)*HorzRatio/10000;

SetRect(&rt,width,crt.top,width+VGAP,crt.bottom);

if (PtInRect(&rt,pt)) {

bHorz=TRUE;

}

}

if (bHorz && bVert) {

SetCursor(LoadCursor(NULL,IDC_SIZEALL));

return TRUE;

}

if (bHorz) {

SetCursor(LoadCursor(NULL,IDC_SIZEWE));

return TRUE;

}

if (bVert) {

SetCursor(LoadCursor(NULL,IDC_SIZENS));

return TRUE;

}

}

return FORWARD_WM_SETCURSOR(hWnd,hwndCursor,codeHitTest,msg,DefWindowProc);

}

커서를 변경할 가장 우선 조건은 어떤 방향으로든 일단 분할되어 있어야 하고 작업 영역내부여야 한다. 사실 분할되어 있지 않을 때는 이 함수가 호출되지 않는데 왜냐하면 뷰가 프레임의 작업 영역을 완전히 덮고 있기 때문에 프레임의 작업 영역에 마우스가 위치할 수 없기 때문이다. 분할되어 있지 않으면 DefWindowProc으로 이 메시지를 보내 디폴트 처리한다.

분할되어 있으면 방향에 따라 스플릿 바의 좌표와 커서의 좌표를 비교해 보고 bVert와 bHorz 변수에 그 결과를 조사한다. 수직 스플릿 바 위에 있으면 bVert가 TRUE가 되며 수평 스플릿 바 위에 있으면 bHorz가 TRUE가 된다. 4분할되어 있고 양방향 스플릿 바의 교점에 커서가 있을 때는 두 값이 모두 TRUE가 될 수도 있다. 이 두 변수의 값에 따라 커서를 변경하되 스톡 커서를 사용하였다.

스플릿 바를 드래그할 때 분할 비율을 조정하는데 이 작업은 마우스 버튼 누름, 이동, 놓음 세 메시지에서 처리한다. 이 메시지들도 편집창이 분할되어 프레임의 작업 영역 일부가 드러나 있을 때만 전달되며 분할되지 않았을 때는 발생할 수 없다. 세 함수의 코드는 뷰의 분할 시작 코드와 거의 유사하다.

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

{

RECT crt,vrt,hrt;

POINT pt;

int width,height;

GetClientRect(hWnd,&crt);

pt.x=x;

pt.y=y;

SplitPt=pt;

height=(crt.bottom-VGAP)*VertRatio/10000;

SetRect(&vrt,crt.left,height,crt.right,height+VGAP);

width=(crt.right-VGAP)*HorzRatio/10000;

SetRect(&hrt,width,crt.top,width+VGAP,crt.bottom);

// 수직 스플릿 바 드래그 시작

if (VertRatio && PtInRect(&vrt,pt)) {

iDrag=AESPLIT_VERT;

OldSplitY=height;

DrawSplitBar(AESPLIT_VERT,OldSplitY);

}

// 수평 스플릿 바 드래그 시작

if (HorzRatio && PtInRect(&hrt,pt)) {

iDrag |= AESPLIT_HORZ;

OldSplitX=width;

DrawSplitBar(AESPLIT_HORZ,OldSplitX);

}

if (iDrag) {

SetCapture(hWnd);

}

}

void CApiEdit::OnMouseMove(HWND hWnd, int x, int y, UINT keyFlags)

{

RECT crt;

int tx,ty;

if (iDrag==0) {

return;

}

GetClientRect(hWnd,&crt);

// 수직 스플릿 바 이동

if (iDrag & AESPLIT_VERT) {

ty=min(max(y,crt.top),crt.bottom-VGAP);

if (OldSplitY!=ty) {

DrawSplitBar(AESPLIT_VERT,OldSplitY);

OldSplitY=ty;

DrawSplitBar(AESPLIT_VERT,OldSplitY);

}

}

// 수평 스플릿 바 이동

if (iDrag & AESPLIT_HORZ) {

tx=min(max(x,crt.left),crt.right-VGAP);

if (OldSplitX!=tx) {

DrawSplitBar(AESPLIT_HORZ,OldSplitX);

OldSplitX=tx;

DrawSplitBar(AESPLIT_HORZ,OldSplitX);

}

}

}

void CApiEdit::OnLButtonUp(HWND hWnd, int x, int y, UINT keyFlags)

{

RECT crt;

if (iDrag==0) {

return;

}

GetClientRect(hWnd,&crt);

// 수직 스플릿 비율 조정

if (iDrag & AESPLIT_VERT) {

DrawSplitBar(AESPLIT_VERT,OldSplitY);

if (y != SplitPt.y) {

VertRatio=OldSplitY*10000/(crt.bottom-VGAP);

}

}

// 수평 스플릿 비율 조정

if (iDrag & AESPLIT_HORZ) {

DrawSplitBar(AESPLIT_HORZ,OldSplitX);

if (x != SplitPt.x) {

HorzRatio=OldSplitX*10000/(crt.right-VGAP);

}

}

iDrag=0;

ReleaseCapture();

SendMessage(hWnd,WM_SIZE,0,0);

InvalidateRect(hWnd,NULL,TRUE);

}

스플릿 바 위에서 마우스 버튼을 누를 때 어떤 방향으로 분할 비율을 조정할 것인지를 iDrag 변수에 대입하고 분할을 시작한 좌표를 기억해 둔다. 동시에 두 방향으로 드래그할 수 있으므로 iDrag는 수평, 수직값을 같이 가질 수도 있다. 최초 반전 막대를 그려 주고 커서는 캡처한다. 이 상태에서 마우스가 이동될 때 반전 막대는 커서를 졸졸 따라 다니며 마우스 버튼을 놓을 때 현재 커서의 좌표값에 따라 분할 비율을 재조정한다. 비율 조정이 끝났으므로 iDrag는 0이 되고 커서 캡처는 푼다.

이 세 함수가 하는 일은 스플릿 바를 드래그할 때 반전 막대를 같이 이동시키고 이동 결과를 HorzRatio, VertRatio에 대입하는 것 뿐이다. 이 두 변수의 값을 변경해 놓고 WM_SIZE 메시지만 보내면 조정된 비율에 따라 뷰를 재배치하는 작업은 OnSize가 담당한다. 조정된 결과대로 스플릿 바를 다시 그리기 위해 프레임의 작업 영역을 무효화했다.

비율 계산에 정수 나누기를 하기 때문에 마우스로 스플릿 바를 눌렀다가 바로 떼기만 해도 분할 비율이 조정될 수 있다. 마우스 버튼을 누를 때 위쪽 뷰의 높이를 비율로부터 계산하고 마우스 버튼을 놓을 때 마우스의 새 위치로부터 다시 비율을 계산하는데 마우스가 그 자리에 가만 있더라도 비율은 변경된다. 왜냐하면 정수 나눗셈에 의한 오차가 발생하기 때문이다. 그래서 최초 누른 좌표를 SplitPt에 대입해 놓고 버튼을 놓을 때 이 위치와 같은 자리이면 비율을 다시 계산하지 않게 했다.

나. 분할 해제

분할을 시작하는 장치인 스플릿 박스는 뷰에 있고 분할 비율을 조정하는 스플릿 바는 프레임에 있지만 분할을 해제하는 장치는 별도로 제공되지 않는다. 대신 스플릿 바로 분할 비율을 조정한 결과 한쪽 뷰의 비율이 5%이하일 때 이 뷰를 제거하는 규칙이 있으므로 뷰를 아주 작게 만들면 분할이 해제된다. 즉, 스플릿 바는 분할 비율을 조정함과 동시에 분할을 해제하는 장치이기도 하다. OnLButtonUp에서 분할 비율을 조정한 결과 한쪽 뷰의 비율이 아주 작다면 이 뷰를 제거하여 분할을 해제할 것이다. 다음 함수는 분할 방향에 따라 비율을 점검해 보고 5% 미만의 뷰를 제거하되 뷰의 번호가 연속적이도록 관리한다.

// 분할을 취소한다.

void CApiEdit::UnSplitView(int SplitType)

{

CApiEditText *OldActive;

int i;

OldActive=arView[ActiveView];

if (SplitType==AESPLIT_VERT) {

// 위쪽 비율이 5%일때 위쪽 뷰를 제거한다.

if (VertRatio==500) {

if (arView[2]==NULL) {

DeleteView(0);

arView[0]=arView[1];

arView[1]=NULL;

} else {

DeleteView(0);

arView[0]=arView[2];

arView[2]=NULL;

DeleteView(1);

arView[1]=arView[3];

arView[3]=NULL;

}

VertRatio=0;

}

// 위쪽 비율이 95%일 때 아래쪽 뷰를 제거한다.

if (VertRatio==9500) {

if (arView[2]==NULL) {

DeleteView(1);

} else {

DeleteView(2);

DeleteView(3);

}

VertRatio=0;

}

} else {

if (HorzRatio==500) {

if (arView[2]==NULL) {

DeleteView(0);

arView[0]=arView[1];

arView[1]=NULL;

} else {

DeleteView(0);

arView[0]=arView[1];

DeleteView(2);

arView[1]=arView[3];

arView[3]=NULL;

}

HorzRatio=0;

}

if (HorzRatio==9500) {

if (arView[2]==NULL) {

DeleteView(1);

} else {

DeleteView(1);

arView[1]=arView[2];

DeleteView(3);

arView[2]=NULL;

}

HorzRatio=0;

}

}

AdjustSplitable();

// 분할 취소전의 활성 뷰를 찾아 다시 활성화한다.

for (i=0;i<4;i++) {

if (arView[i] && arView[i]==OldActive) {

break;

}

}

if (i != 4) {

ActiveView=i;

} else {

ActiveView=0;

SetFocus(arView[ActiveView]->hWnd);

}

}

함수의 길이가 무척 긴데 상황에 따른 케이스 분기가 많기 때문이다. 분할 방향에 수직, 수평 두 가지가 있고 비율 조정 결과 5%, 95% 두 가지가 있고 또 현재 분할 상태가 2분할, 4분할 중 하나이므로 총 케이스는 8가지가 된다. 즉, 수직으로 4가지 경우가 있고 수평으로 4가지 경우가 있는데 방향에 따른 처리는 유사하므로 수직인 경우만 분석해 보자.

수직으로 분할 비율이 조정되었을 때는 스플릿 바를 프레임의 상단으로 드래그하여 VertRatio가 500이 된 경우와 하단으로 드래그하여 VertRatio가 9500이 된 경우 두 가지 동작을 할 수 있다. 사용자가 스플릿 바를 프레임의 상단으로 드래그했다는 것은 윗쪽에 있는 뷰를 제거하라는 명령이고 하단으로 드래그했다는 것은 아래쪽에 있는 뷰를 제거하라는 명령이다. 이때 현재 분할 상태가 2분할이면 작아진 뷰 하나만 제거하고 4분할 상태이면 작아진 뷰 2개를 한꺼번에 제거해야 한다. 수직으로 분할 비율을 조정했을 때 4가지 케이스에 대해 이 함수가 어떻게 뷰를 관리하는지 그림으로 정리해 보자.

가장 쉬운 케이스는 2분할 95%일 때인데 이때는 아래쪽의 뷰를 제거하기만 하면 되므로 1번 뷰만 삭제한다. 그러면 위쪽에 있는 0번 뷰만 남고 2분할 상태에서 분할되지 않은 상태로 쉽게 돌아갈 수 있다. 2분할 5%일 때는 위쪽의 0번뷰를 제거해야 하는데 이 뷰를 제거해 버리면 1번 뷰만 남게 되므로 1번을 0번에 대입해야 한다. 4분할 상태일 때도 마찬가지 방법으로 뷰를 제거하되 제거한 후 남은 두 개의 뷰가 0번, 1번이 되도록만 하면 된다.

방향과 분할 비율에 따라 뷰를 정리하고 VertRatio 변수를 0으로 리셋해 놓으면 나머지 배치 작업은 OnSize에서 알아서 한다. 수평 분할 상태일 때는 제거되는 뷰가 다를 뿐이지 논리적으로 다른 점은 거의 없다. 분할이 해제된 후에도 뷰의 번호는 항상 좌에서 우로 위에서 아래로 0번부터 순서대로 번호를 매겨 정규화 상태를 유지한다는 것만 주의하면 된다.

분할 해제 후 AdjustSplitable 함수를 호출하여 각 뷰의 분할 가능성을 조정한다. 수직으로 분할된 상태일 때 각 뷰는 더 이상 수직으로 분할할 수 없는데 분할이 해제되면 다시 수직으로 분할 가능하도록 스플릿 박스를 표시해야 하며 이 작업을 AdjustSplitable 함수가 담당한다. 이 함수의 또 다른 중요한 임무는 분할 해제 후 활성 뷰를 관리하는 것이다. 프레임의 모든 동작은 활성 뷰를 대상으로 하므로 활성 뷰가 없는 상태를 만들어서는 안된다. 그래서 이 함수는 분할을 해제하기 전에 활성 뷰의 포인터를 OldActive에 저장해 놓고 뷰를 제거한 후 원래 활성 뷰가 아직도 남아 있는지 찾아 본다. 만약 활성 뷰가 아직 생존해 있다면 이 뷰를 다시 활성화시키고 활성 뷰가 제거되어 버렸다면 어쩔 수 없이 0번 뷰에게 포커스를 준다.

활성 뷰는 arView 배열의 첨자로 관리되지만 뷰의 번호로 원래 활성뷰를 기억하는 방법은 사용할 수 없다. 왜냐하면 이 함수는 뷰를 제거하기만 하는 것이 아니라 제거 후에 뷰의 첨자를 조정하여 정규화하기 때문에 원래 활성 뷰의 번호가 조정 후에도 계속 같은 뷰를 가리키지 못하기 때문이다. 예를 들어 위의 그림에서 4분할 5% 상태의 1번 뷰가 활성 뷰였을 때 조정 후의 1번 뷰는 원래 3번 뷰이기 때문에 활성 뷰가 그대로 유지되는 것이 아니다. 그래서 활성 뷰의 포인터를 저장해 놓고 조정 후에 포인터를 비교하여 활성 뷰 존재 여부를 조사하였다. 이 함수는 마우스 버튼을 놓을 때인 OnLButtonUp에서 분할 비율을 조정한 후 그리고 WM_SIZE 메시지를 보내기 전에 호출한다.

void CApiEdit::OnLButtonUp(HWND hWnd, int x, int y, UINT keyFlags)

{

....

GetClientRect(hWnd,&crt);

// 수직 스플릿 비율 조정

if (iDrag & AESPLIT_VERT) {

DrawSplitBar(AESPLIT_VERT,OldSplitY);

if (y != SplitPt.y) {

VertRatio=OldSplitY*10000/(crt.bottom-VGAP);

VertRatio=max(min(VertRatio,9500),500);

UnSplitView(AESPLIT_VERT);

}

}

// 수평 스플릿 비율 조정

if (iDrag & AESPLIT_HORZ) {

DrawSplitBar(AESPLIT_HORZ,OldSplitX);

if (x != SplitPt.x) {

HorzRatio=OldSplitX*10000/(crt.right-VGAP);

HorzRatio=max(min(HorzRatio,9500),500);

UnSplitView(AESPLIT_HORZ);

}

}

....

분할 비율은 최소 500에서 최대 9500까지의 범위를 가지도록 조정되는데 그래서 UnSplitView 함수에서는 분할 비율을 부등식으로 비교하지 않고 등식으로 비교가 가능하다. 만약 분할 비율이 500 초과 9500 미만이라면 UnSplitView 함수는 아무 것도 하지 않고 그냥 리턴할 것이다.

여기까지 코드를 작성한 후 실행해 보면 스플릿 박스를 드래그하여 편집창을 분할할 수 있으며 분할 후에는 스플릿 바로 비율을 조정할 수 있고 프레임의 상단이나 하단으로 드래그하면 분할을 해제할 수도 있다. 분할 및 해제를 임의의 방향으로 여러 번 반복해도 전혀 무리가 없는데 이때마다 뷰가 생겼다가 없어졌다가를 반복한다.

다. 더블 클릭 처리

스플릿 박스를 드래그하면 분할과 동시에 원하는 비율을 선택할 수 있다. 이 방법 외에 좀 더 간편한 방법으로 스플릿 박스의 더블클릭을 정의하여 절반 비율로 분할해 보자. 뷰의 StartSplit에 다음 코드를 추가한다.

BOOL CApiEditText::StartSplit(HWND hWnd,BOOL fDoubleClick,int x,int y)

{

RECT crt;

GetClientRect(hWnd,&crt);

if (bVertSplit && x > crt.right-SBW && y < SPLITWIDTH) {

if (fDoubleClick) {

pFrame->SplitView(AESPLIT_VERT,5000);

return TRUE;

}

iDrag=AESPLIT_VERT;

}

if (bHorzSplit && x < SPLITWIDTH && y > crt.bottom-SBW) {

if (fDoubleClick) {

pFrame->SplitView(AESPLIT_HORZ,5000);

return TRUE;

}

iDrag=AESPLIT_HORZ;

}

....

더블클릭 동작은 StartSplit함수내에서 완결되므로 커서를 캡처하거나 iDrag값을 조정할 필요없이 바로 분할 가능하다. 프레임의 SplitView 함수를 호출하되 분할 비율로 5000을 주면 정확하게 절반으로 분할될 것이다. 이왕 스플릿 박스를 만들었으니 이 조그만 사각 영역에 대해서도 가급적이면 많은 동작을 허용한다는 점에서 의미가 있다. 다음은 분할된 상태에서 스플릿 바를 더블클릭했을 때의 동작도 정의해 보자. 이 동작은 분할을 해제하라는 명령으로 해석하여 분할 비율을 조정하고 UnSplitView 함수를 호출한다. 스플릿 바는 프레임이 가지므로 이 코드는 프레임의 OnLButtonDown에 작성한다.

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

{

....

SetRect(&hrt,width,crt.top,width+VGAP,crt.bottom);

// 더블 클릭하면 분할을 취소한다.

if (fDoubleClick) {

if (VertRatio && PtInRect(&vrt,pt)) {

if (ActiveView==0 || (arView[2] && ActiveView==1)) {

VertRatio=9500;

} else {

VertRatio=500;

}

UnSplitView(AESPLIT_VERT);

}

if (HorzRatio && PtInRect(&hrt,pt)) {

if (ActiveView==0 || (arView[2] && ActiveView==2)) {

HorzRatio=9500;

} else {

HorzRatio=500;

}

UnSplitView(AESPLIT_HORZ);

}

SendMessage(hWnd,WM_SIZE,0,0);

InvalidateRect(hWnd,NULL,TRUE);

return;

}

....

이때 어떤 방향을 해제할 것인가에 따라 분할 비율을 500또는 9500으로 변경하는데 두 가지 정책을 생각해 볼 수 있다. 첫 번째는 분할 비율이 작은 쪽을 제거하는 것이고 두 번째는 활성 뷰를 가지지 않은 반대쪽을 제거하는 것이다. 아무래도 당장 보이는 크기보다는 활성뷰에 더 큰 의미가 있는 것 같으므로 당근은 후자를 선택했다. 분할되지 않은 상태에서 스플릿 박스를 더블클릭하면 절반으로 분할되며 분할된 상태에서 스플릿 바를 더블클릭하면 분할이 해제될 것이다. 4분할된 상태에서 스플릿 바의 교점을 더블클릭하면 모든 분할이 즉시 해제된다.

라. 활성 뷰 관리

편집창 하나가 여러 개의 뷰로 분할될 수 있는데 반해 사용자는 여전히 한 명뿐이고 따라서 편집은 활성 뷰 하나에서만 가능하다. 활성 뷰라는 개념은 포커스를 가지고 있어 캐럿이 보이고 사용자의 편집을 받아들이는 뷰라는 뜻이다. 프레임은 ActiveView라는 변수에 항상 활성 뷰를 기억하며 모든 편집 명령은 활성 뷰를 대상으로 한다. 활성 뷰는 사용자의 명시적인 명령이나 뷰의 요구에 의해 수시로 변경될 수 있으므로 프레임은 활성 뷰간의 전환을 관리해야 한다. 다음 멤버 함수가 활성 뷰를 관리한다.

// 활성 뷰를 전환한다. Who = 0:자기 자신, 1:다음 뷰, 2:이전 뷰

void CApiEdit::ChangeActiveView(CApiEditText *pAe,int Who)

{

int i,Next;

// pAe를 활성 뷰로 만든다.

for (i=0;i<4;i++) {

if (arView[i]==pAe) {

ActiveView=i;

}

}

// 분할되어 있지 않거나 자신을 활성화할 때는 아무 것도 할 필요가 없다.

if (arView[1]!=NULL && Who!=0) {

// 유효한 다음 뷰 검색

if (Who==1) {

for (Next=ActiveView;;) {

Next = (Next == 3 ? 0:Next+1);

if (arView[Next]) {

ActiveView=Next;

break;

}

}

// 유효한 이전 뷰 검색

} else {

for (Next=ActiveView;;) {

Next = (Next == 0 ? 3:Next-1);

if (arView[Next]) {

ActiveView=Next;

break;

}

}

}

// 검색된 뷰에게 포커스를 넘긴다.

SetFocus(arView[Next]->hWnd);

}

}

인수로 뷰 전환을 요청한 뷰의 포인터와 누구를 활성화시킬 것인가를 지정하는 Who를 전달받는데 Who가 0이면 자기 자신, 1이면 다음 뷰, 2이면 이전 뷰이다. 자기 자신을 활성화시켜 달라고 요청할 때는 ActiveView만 변경하면 된다. 이 상태에서는 자신이 이미 포커스를 가진 상태에서 프레임에게 자신이 활성뷰가 되었음을 신고하는 것이므로 SetFocus를 호출할 필요가 없다. 이전, 다음 뷰를 활성화할 때는 뷰의 첨자를 증감시켜 유효한 뷰를 찾아 활성 뷰를 선택하고 SetFocus를 호출하여 새로 활성화된 뷰에게 포커스까지 넘긴다. ChangeActiveView 함수는 분할이 되어 있지 않을 때 즉, 뷰가 하나밖에 없으면 아무 동작도 하지 않는다. arView[1]이 NULL이 아니어야 다음 뷰나 이전 뷰를 찾는다.

뷰는 마우스 입력을 받아들일 수 있으므로 프레임이 별도로 신경쓰지 않아도 스스로 활성화가 가능하다. 하지만 자신이 활성화되었다는 사실을 프레임에게 알려 앞으로의 편집 명령을 자신에게 보내줄 것을 요청할 필요가 있다. 뷰는 포커스를 받았을 때 프레임의 ChangeActiveView 함수를 호출하여 자기 자신을 활성화해 줄 것을 요청한다.

void CApiEditText::OnSetFocus(HWND hWnd, HWND hwndOldFocus)

{

....

pFrame->ChangeActiveView(this,0);

}

사용자가 마우스로 뷰를 클릭하면 이 뷰는 스스로 활성화되면서 프레임의 ActiveView를 자신으로 변경함으로써 이 후의 편집 동작이나 분할 뷰 관리에 참고하도록 한다. 뷰 사이를 전환할 때는 F6, Shift+F6 단축키를 정의한다.

void CApiEditText::OnKey(HWND hWnd, UINT vk, BOOL fDown, int cRepeat, UINT flags)

{

....

case VK_F6:

pFrame->ChangeActiveView(this,(bShift ? 2:1));

return;

뷰 전환은 컨트롤 자체의 기능이므로 외부의 도움없이도 스스로 활성 뷰를 바꿀 수 있어야 하며 그래서 뷰의 OnKey에서 단축키 입력을 직접 받아 활성 뷰를 전환했다. 물론 외부에서 강제로 활성 뷰를 바꾸는 것도 가능하다. 창 메뉴에 두 개의 메뉴 항목과 액셀러레이터가 이미 준비되어 있으므로 코드만 작성하면 된다.

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

{

....

case IDM_WIN_NEXTVIEW:

pSi->Ae.ChangeActiveView(pView,1);

break;

case IDM_WIN_PREVVIEW:

pSi->Ae.ChangeActiveView(pView,2);

break;

메뉴에 이 명령을 넣어 놓는 것은 안내 이외의 의미는 별로 없다. 단축키가 있는데 메뉴를 선택해서 뷰를 전환하는 사용자는 거의 없을 것이다. 그래도 메뉴에 없으면 뷰 전환 단축키가 있다는 사실조차 알기 어렵기 때문에 메뉴에 포함시켜 놓는 것이다. 분할되어 있지 않을 때 사용금지 시키는 것이 옳으나 호스트에서 분할 여부를 판단하기 어려워 그렇게 하지 않았다. 호스트가 F6, Shift+F6에 대해 먼저 처리하기 때문에 ApiEdit는 실제로 F6 입력을 받지 못한다. 그러나 F6을 처리하지 않는 호스트를 위해 OnKey의 F6 처리 코드는 생략할 수 없다.

마. 뷰 변경 관리

분할된 뷰들은 모두 같은 문서의 다른 부분을 보여주고 있는 것이므로 한쪽 뷰에서 변화가 발생하면 나머지 뷰도 같이 갱신되어야 한다. 뷰는 자신 외에 다른 뷰의 존재 여부 조차도 모르므로 뷰를 갱신하는 작업은 프레임이 해야 하며 변화를 만든 뷰는 프레임에게 나머지 뷰의 갱신을 요청하는데 이때 호출되는 함수가 UpdateViews 함수이다.

이 함수는 앞서 SplitView 예제로 분할 실습을 할 때 그 필요성과 구체적인 동작 방식에 대해서 연구해 본 바 있으므로 그대로 적용하기만 하면 된다. 다만 최대한 불필요한 갱신을 하지 않기 위해 다양한 힌트 정보를 받아들인다는 점에 있어서 좀 더 기능이 확장되었을 뿐이다. 프레임에 다음 멤버 함수를 추가한다.

// 형제 뷰들을 모두 갱신한다. nPos와 nCount는 변경된 위치와 길이 정보이다.

void CApiEdit::UpdateViews(CApiEditText *pView,int nPos,int nCount)

{

int i;

// 존재하는 모든 뷰(pView 제외)를 갱신한다.

for (i=0;i<4;i++) {

if (arView[i] && arView[i]!=pView) {

if (nCount) {

if (arView[i]->off >= nPos) {

arView[i]->off=max(arView[i]->off+nCount,nPos);

}

if (arView[i]->SelStart >= nPos) {

arView[i]->SelStart=max(arView[i]->SelStart+nCount,nPos);

}

if (arView[i]->SelEnd >= nPos) {

arView[i]->SelEnd=max(arView[i]->SelEnd+nCount,nPos);

}

if (arView[i]->ViewType != HEXA_VIEW) {

arView[i]->UpdateLineInfo(nPos,nCount);

}

arView[i]->UpdateScrollInfo();

}

if (arView[i]->ViewType != HEXA_VIEW) {

arView[i]->Invalidate(FindParaStart(nPos));

} else {

arView[i]->Invalidate(nPos);

}

}

}

}

이 함수는 세 개의 인수를 받아들이는데 첫번째 인수 pView는 변화를 유발시킨 뷰의 포인터이며 이 뷰가 나머지 뷰의 변경을 요청한다. pView자체는 이 요청을 하기 전에 이미 자신을 갱신했기 때문에 변경의 대상에서 제외된다. 만약 자기 자신까지 같이 갱신해야 한다면 pView를 NULL로 전달하면 된다. nPos는 변화가 발생한 오프셋이며 nCount는 삽입, 삭제된 바이트 수이다. UpdateViews 함수는 이 힌트 정보를 각 뷰에게 알려 줌으로써 최대한 좁은 지역만 갱신할 수 있게 도와준다.

갱신되는 정보는 오프셋, 선택 영역, 정렬 정보, 스크롤 정보 등이 있고 이런 정보들이 변경되면 화면도 당연히 다시 그려야 한다. 먼저 오프셋이 어떻게 변경되는지 보자. 편집이 발생한 부분이 현재 뷰의 오프셋과 같은 위치이거나 더 앞쪽에 있을 때는 오프셋이 같이 이동되어야 하지만 더 뒤쪽이라면 오프셋은 이동할 필요가 없다.

두 개의 뷰로 분할되어 있고 뷰0에서 "분할"이라는 문자열을 삽입한 상황인데 이때 뷰1의 현재 위치가 어디인가 따라 뷰1의 off가 어떻게 변할 것인가가 달라진다. 그림에서 뷰1의 off가 현재 위치1에 있는 상황을 보면 off보다 더 뒤쪽에서 편집이 일어났으므로 이때의 off는 그 자리에 가만히 있으면 원래 가리키고 있던 "의"자 위치를 그대로 가리킬 수 있다.

반면 현재 위치2인 "다"에 있는 상황은 좀 다른데 이 위치보다 앞쪽에 4바이트가 삽입되었으므로 뷰1의 off도 그만큼 뒤로 이동해야 갱신전의 "다"위치를 그대로 가리킬 수 있다. 만약 이때 off를 조정하지 않는다면 갱신 후의 off는 "다"자보다 4바이트 앞쪽을 가리키게 될 것이며 이는 치명적인 에러의 원인이 될 수도 있다.

이 두가지 케이스외에 아주 특수한 경우로 변화 구간에 속해 있는 경우를 생각해 볼 수 있는데 이때는 변화가 발생된 시작 지점으로 off를 강제로 옮겨야 한다. 뷰1의 오프셋을 감싸는 영역을 선택한 후 삭제할 때가 이 경우에 해당하는데 현재 위치의 문자가 없어져 버렸으므로 오프셋은 선택 영역의 처음으로 이동할 수밖에 없다.

뷰1의 현재 위치는 "뷰"자에 있고 뷰0에서 이 오프셋을 포함한 "개의 뷰가"문자열을 통째로 삭제해 버렸다. 이렇게 되면 뷰1은 원래 가리키고 있던 문자가 삭제되어 버렸으므로 어떻게 하더라도 원래 문자를 가리킬 수 없으므로 불가피하게 삭제된 문자열의 선두 위치로밖에 갈 수가 없는 것이다. 이런 모든 경우를 고려하여 뷰의 off를 조정하는 코드는 다음과 같아진다.

if (arView[i]->off >= nPos) {

arView[i]->off=max(arView[i]->off+nCount,nPos);

}

off가 편집된 nPos이상일 때에 한해 off에 nCount를 더하되 nCount가 음수일 경우, 즉 삭제될 때는 최소한 nPos보다 더 작은 오프셋으로 이동하지 않게 한다. SelStart와 SelEnd도 오프셋과 동일한 성격의 값이므로 똑같은 코드로 조정할 수 있다. 따라서 뷰1의 선택 영역 안을 뷰0에서 편집하면 뷰1의 선택 영역이 확장/축소되는 효과가 있다.

오프셋과 선택 영역을 조정한 후 삽입, 삭제된 바이트 수에 맞게 재정렬하고 스크롤 정보도 갱신한다. 재정렬할 때도 UpdateLineInfo 함수에게 어디서 얼마만큼 편집이 발생했다는 힌트를 제공하여 정렬 최적화 코드가 동작할 수 있게 해야 한다. 그리고 최종적으로 편집된 부분을 무효화하여 화면을 다시 그리면 모든 갱신이 완료된다. 다음 장에서 만들 헥사 뷰는 문단의 개념이 없으므로 정렬 정보가 없으며 UpdateLineInfo 함수도 필요없다. 뷰는 자신이 문서의 일부를 변경할 때마다 프레임의 UpdateViews 함수를 호출하여 나머지 뷰도 제대로 갱신되도록 해야 한다. 이 함수를 호출해야 할 시점은 세 군데가 있는데 다음 둘은 아주 쉽게 이해될 것이다.

void CApiEditText::Insert(int nPos, TCHAR *str, BOOL bRec/*=TRUE*/)

{

....

pFrame->UpdateViews(this,nPos,lstrlen(str));

}

void CApiEditText::Delete(int nPos, int nCount, BOOL bRec/*=TRUE*/)

{

....

pFrame->UpdateViews(this,nPos,-nCount);

}

문자열을 삽입, 삭제했을 때 당연히 문서가 변경되므로 UpdateViews 함수를 호출해야 한다. 최적화를 하지 않았다면 문서를 변경하는 곳은 이 두 군데뿐이겠지만 최적화에 의해 이 함수를 호출해야 하는 곳이 한 군데 더 있다.

LRESULT CApiEditText::OnImeComposition(HWND hWnd, WPARAM wParam, LPARAM lParam)

{

....

if (lParam & GCS_COMPSTR) {

len=ImmGetCompositionString(hImc,GCS_COMPSTR,NULL,0);

szComp=(TCHAR *)malloc(len+1);

ImmGetCompositionString(hImc,GCS_COMPSTR,szComp,len);

szComp[len]=0;

if (bComp && len!=0) {

pFrame->buf[off-2]=szComp[0];

pFrame->buf[off-1]=szComp[1];

pFrame->UpdateViews(this,off-2,0);

....

조립중인 글자를 대체할 때도 buf를 직접 변경했으므로 다른 뷰에서 이 사실을 알 수 있도록 한다. 한글 조립 속도를 높이고자 Insert, Delete를 부르지 않았기 때문에, 즉 길목을 피해 다녔기 때문에 이 부분은 항상 신경을 써야 하는 골치 덩어리가 되어 버렸다. 이때는 버퍼를 직접 조작하여 기존 문자를 대체했으므로 버퍼의 길이가 늘어나거나 줄어들지 않으며 UpdateViews 함수로 전달되는 nCount인수는 0이다.

UpdateViews 함수는 nCount가 0이 아닐 때만 오프셋, 선택 영역 조정, 재정렬을 하며 nCount가 0일 때는 편집 위치를 무효화하여 화면만 다시 그리는데 한글 조립중에는 굳이 복잡한 계산을 할 필요가 없기 때문이다. Undo, Redo도 문서를 변경시키지만 이 함수들은 Insert, Delete를 호출하므로 별도로 나머지 뷰를 관리할 필요가 없다.

문서 변경시의 뷰 갱신외에 옵션이 변경될 때도 분할된 뷰를 모두 갱신해야 한다. 호스트에서 옵션을 변경하면 프레임의 Set 함수를 호출하고 프레임의 Set 함수는 ForAllView 매크로로 존재하는 모든 뷰로 옵션을 전달한다. 그래서 글꼴이나 색상 등을 바꾸면 분할된 창에 일괄 적용된다. 그런데 한가지 예외가 있는데 구문 분석기의 색상 설정은 분할뷰로 전달되지 않으며 활성뷰에게만 적용된다. 문법 옵션은 덩치가 크기 때문에 ApiEdit가 설정 함수를 가지지 않고 SOption의 SetStyleColor 함수가 직접 변경한다. 여기에도 분할 뷰에 옵션을 적용하는 코드를 작성해야 한다.

void ApplyNow()

{

....

if (bChangeStyle) {

for (int aet=0;aet<4 && pSi->Ae.arView[aet];aet++) {

NewOption.SetStyleColor(pSi->Ae.arView[aet]->GetParser());

}

pSi->Ae.Invalidate(-1);

}

ForAllView 매크로와 마찬가지로 존재하는 모든 뷰를 순회하며 SetStyleColor 함수를 호출하여 각 뷰의 분석기 객체에 옵션을 적요한다.

바. 분할 금지

텍스트 뷰는 각 방향에 대해 분할이 가능한지를 bHorzSplit, bVertSplit 변수로 기억하며 이 두 값의 디폴트는 모두 TRUE이다. 또한 프레임은 분할 가능한 방향을 SplitFlag로 기억하며 생성자에서 이 값을 양방향 모두 분할 가능하도록 초기화한다. 따라서 ApiEdit 컨트롤을 디폴트 속성대로 생성하기만 하면 호스트가 특별한 지원을 하지 않더라도 컨트롤 스스로 분할이 가능하며 분할된 뷰를 알아서 관리할 수 있는 능력이 있다.

호스트의 입장에서 볼 때 컨트롤의 이런 자동화된 분할 관리가 무척 편리할 수도 있겠지만 때로는 이 기능이 호스트와 맞지 않을 수도 있다. 예를 들어 주소나 사람 이름같은 짧은 문자열을 입력받기 위해 ApiEdit 컨트롤을 사용하는데 이런 조그만 컨트롤도 분할이 된다면 좀 우스워 보이고 비록 작지만 스플릿 박스가 눈에 거슬릴 수도 있다. 그래서 호스트가 원할 경우는 분할 기능을 사용 금지할 필요가 있다. ApiEdit는 이런 목적으로 분할 가능한 방향을 SplitFlag라는 멤버 변수로 관리하며 이 변수의 값은 다음 함수로 조정한다.

void CApiEdit::EnableSplit(DWORD Flag)

{

if (arView[1]) {

return;

}

SplitFlag=Flag;

AdjustSplitable();

return;

}

인수로 전달된 Flag를 SplitFlag에 대입하고 각 뷰의 분할 가능성 여부를 조정하기 위해 AdjustSplitable 함수를 호출한다. AdjustSplitable 함수는 현재 분할 상태뿐만 아니라 SplitFlag값을 같이 참조하여 각 뷰의 스플릿 박스를 통제한다.

// 분할된 뷰의 스플릿 박스를 관리한다.

void CApiEdit::AdjustSplitable()

{

int i;

// 분할되어 있지 않으면 양방향 분할 가능

if (arView[1]==NULL) {

arView[0]->SetHorzSplit(TRUE && (SplitFlag & AESPLIT_HORZ));

arView[0]->SetVertSplit(TRUE && (SplitFlag & AESPLIT_VERT));

// 2분할되어 있으면 분할되지 않은쪽만 분할 가능

} else if (arView[2]==NULL) {

if (VertRatio) {

arView[0]->SetHorzSplit(TRUE && (SplitFlag & AESPLIT_HORZ));

arView[0]->SetVertSplit(FALSE);

arView[1]->SetHorzSplit(TRUE && (SplitFlag & AESPLIT_HORZ));

arView[1]->SetVertSplit(FALSE);

} else {

arView[0]->SetHorzSplit(FALSE);

arView[0]->SetVertSplit(TRUE && (SplitFlag & AESPLIT_VERT));

arView[1]->SetHorzSplit(FALSE);

arView[1]->SetVertSplit(TRUE && (SplitFlag & AESPLIT_VERT));

}

// 4분할되어 있으면 더 이상 분할할 수 없다.

} else {

for (i=0;i<4;i++) {

arView[i]->SetHorzSplit(FALSE);

arView[i]->SetVertSplit(FALSE);

}

}

}

비록 분할되어 있지 않더라도 SplitFlag에 분할 허용 플래그가 설정되어 있어야만 뷰에 스플릿 박스를 표시한다. 스플릿 박스만 제거하면 최초 분할을 시작할 수 있는 사용자 인터페이스가 사라지므로 실질적으로 분할할 수 없는 상태나 마찬가지다. 호스트에서 EnableSplit(0)를 호출하면 양방향 모두 분할이 금지되며 EnableSplit(AESPLIT_HORZ)를 호출하면 수평으로만 분할할 수 있고 수직으로는 분할할 수 없다.

EnableSplit 함수의 코드를 보면 알 수 있겠지만 SplitFlag값을 변경할 때는 분할이 되어 있지 않아야만 한다. 즉, 이미 분할되어 있는 상태에서 이 함수를 호출하여 분할을 금지할 수는 없는데 왜냐하면 이미 분할되어 있는 창을 강제로 해제하는 것이 까다롭기 때문이다. 따라서 분할 기능을 사용하고 싶지 않은 호스트는 ApiEdit 컨트롤을 만든 직후에 곧바로 이 함수를 호출해야 하며 실행중에는 쓰지 않는 것이 좋다.

왜 EnableSplit 함수를 사용하는 방법이 이렇게 까다로운가 하면 이 함수는 프로그래밍 인터페이스이지 사용자 인터페이스가 아니기 때문이다. 즉, ApiEdit 컨트롤을 사용하는 개발자를 위해 제공되는 함수일 뿐 최종 사용자들이 쓰는 함수가 아니다. 당근은 항상 분할 가능하게 동작하기를 원하므로 이 함수를 호출하지 않으며 설정 대화상자에도 "분할 금지하기" 이런 옵션을 만들지 않는다.