1.창 분할

가. 스크롤 바 컨트롤

앞장에서 힘들게 객체를 분할해 놓았으니 이제 객체들을 잘 요리해서 편집창을 분할해 보자. 이 실습을 마치고 나면 한 파일의 두 곳을 동시에 보면서 편집할 수 있다. 늘 그래왔듯이 Dangeun14를 복사하여 새로운 Dangeun15 프로젝트를 새로 작성하고 실습을 시작한다. 이 실습도 앞장에서 이미 해 보았던 SplitView 예제를 따라 하되 실제 프로젝트에 적용해야 하므로 조금 더 양이 많고 사소한 문제까지도 고려해야 한다는 점에서 다소 까다롭다.

창 분할은 컨트롤의 고유 기능이므로 외부의 도움이 없어도 컨트롤이 스스로 분할을 시작할 수 있어야 한다. 그래서 창 분할을 시작할 수 있는 유저 인터페이스도 컨트롤이 가지는데 프레임은 뷰에 완전히 가려져 있기 때문에 분할 명령을 위한 화면 영역을 가질 수 없다. 그래서 최초의 분할 명령을 위한 유저 인터페이스를 뷰가 제공해야 한다.

뷰의 스크롤 바 위에 조그만 사각 박스를 만들고 사용자가 이 사각 박스를 드래그하면 분할을 시작할 것이다. 이 박스를 스플릿 박스(Split Box)라고 하는데 항상 화면에 보이기 때문에 직관적이며 편집창을 분할하는 가장 표준적인 방법이다. 비주얼 스튜디오의 편집기를 보면 수직 스크롤 바 위에 조그만 사각 박스가 있는데 이것이 바로 스플릿 박스이다. 이 부분을 마우스로 드래그하면 수직으로 편집창이 분할된다.

스크롤 바 위에 스플릿 박스를 배치하려면 표준 스크롤 바는 쓸 수 없다. 왜냐하면 표준 스크롤 바가 차지하는 영역은 아예 작업 영역에서 제외되어 버리기 때문에 윈도우가 이 영역을 건드릴 수 없기 때문이다. 그래서 마음대로 프로그래밍할 수 있는 스크롤 바 컨트롤을 대신 사용해야 한다. 스크롤 바 컨트롤은 버튼이나 에디트처럼 위치나 크기를 마음대로 조작할 수 있으므로 스크롤 바 위에 스플릿 박스를 위한 여백을 만들 수 있다. ApiEdit.h에 다음 상수를 선언한다.

#define AEID_VERTSCROLL 1

#define AEID_HORZSCROLL 2

#define AEID_BTNSETTING 3

#define SPLITWIDTH 8

#define SBW GetSystemMetrics(SM_CXHSCROLL)

스크롤 바 컨트롤의 ID와 스플릿 박스의 폭을 정의하는 매크로이다. SBW는 스크롤 바의 폭을 정의하는 시스템 메트릭스 값을 구하는 매크로 함수인데 컨트롤 배치에 자주 사용된다. 함수를 호출하는 매크로보다 전역 변수로 정의하고 OnCreate에서 딱 한번만 조사하면 약간의 속도 향상을 기대할 수 있겠지만 빠른 함수이므로 그냥 매크로로 정의했다. 이 값들은 뷰에서 사용하지만 모든 뷰가 다 참조해야 하므로 프레임의 헤더 파일에 상수를 선언하였다. 뷰의 헤더 파일인 ApiEditText.h에는 관련 멤버 변수를 선언한다.

class CApiEditText : public CWindow

{

protected:

....

BOOL bVertSplit;

BOOL bHorzSplit;

HWND hVertScroll;

HWND hHorzScroll;

HWND hBtnSetting;

public:

....

virtual BOOL GetVertSplit() { return bVertSplit; }

virtual void SetVertSplit(BOOL aValue);

virtual BOOL GetHorzSplit() { return bHorzSplit; }

virtual void SetHorzSplit(BOOL aValue);

bVertSplit, bHorzSplit은 수평, 수직 분할을 허용할 것인가를 지정하는 옵션 변수이며 h*는 스크롤 바 컨트롤의 윈도우 핸들이다. hBtnSetting은 두 스크롤 바의 아래와 오른쪽 모서리의 남는 영역에 배치되는 버튼 컨트롤인데 당장은 용도가 정해져 있지 않다. 현재는 빈 자리를 채우기만 하는데 차후에 쓸 일이 있을 것이다. OnCreate에서 두 개의 스크롤 바 컨트롤과 하나의 명령 버튼을 생성하는데 위치와 크기는 실행중에 계산되므로 모두 0으로 준다. 또한 OnCreate에서 분할 허용 플래그를 초기화하며 Set함수는 다음과 같이 작성한다.

BOOL CApiEditText::OnCreate(HWND hWnd, LPCREATESTRUCT lpCreateStruct)

{

....

hVertScroll=CreateWindow("scrollbar",NULL,WS_CHILD | WS_VISIBLE | SBS_VERT,

0,0,0,0,hWnd,(HMENU)AEID_VERTSCROLL,GetModuleHandle(NULL),NULL);

hHorzScroll=CreateWindow("scrollbar",NULL,WS_CHILD | WS_VISIBLE | SBS_HORZ,

0,0,0,0,hWnd,(HMENU)AEID_HORZSCROLL,GetModuleHandle(NULL),NULL);

hBtnSetting=CreateWindow("button","",WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON,

0,0,0,0,hWnd,(HMENU)AEID_BTNSETTING,GetModuleHandle(NULL),NULL);

SetDefaultSetting();

InitView();

bVertSplit=TRUE;

bHorzSplit=TRUE;

return TRUE;

}

void CApiEditText::SetVertSplit(BOOL aValue)

{

if (bVertSplit!=aValue) {

bVertSplit=aValue;

SendMessage(hWnd,WM_SIZE,0,0);

}

}

void CApiEditText::SetHorzSplit(BOOL aValue)

{

if (bHorzSplit!=aValue) {

bHorzSplit=aValue;

SendMessage(hWnd,WM_SIZE,0,0);

}

}

bVertSplit, bHorzSplit을 모두 TRUE로 초기화했으므로 양쪽 방향으로 모두 분할 가능하다. 이 두 변수는 생성될 때 한번만 초기화해야 하므로 OnCreate에 코드를 작성하는데 InitView에서 초기화하는 것이 아님을 주의하자. InitView 함수는 이미 분할 되어 있는 상태에서도 호출될 수 있으므로 이때는 분할 허용 여부를 리셋하지 말아야 한다. OnCreate는 딱 한번만 해야 할 초기화를 담당하며 InitView는 뷰를 재초기화한다는 차이가 있다.

Set 함수들은 인수로 전달된 aValue값을 bHorz(Vert)Split 멤버 변수에 대입하되 중복 처리 방지를 위해 현재값이 새값과 같으면 아무 일도 하지 않는다. 이 값이 변경되면 스플릿 박스를 배치하거나 삭제해야 하므로 WM_SIZE 메시지를 보내 뷰를 재배치한다. OnSize는 분할 가능 플래그의 값에 따라 스크롤 바를 적절히 배치한다.

void CApiEditText::OnSize(HWND hWnd, UINT state, int cx, int cy)

{

RECT crt;

if (state != SIZE_MINIMIZED) {

GetClientRect(hWnd,&crt);

frt=crt;

// 스크롤 바 영역은 편집 영역에서 제외된다.

frt.right-=SBW;

frt.bottom-=SBW;

frt.left += MarginWidth;

// 분할 가능하면 스크롤 바 위, 왼쪽에 스플릿 박스를 위한 여백을 남긴다.

if (bVertSplit) {

MoveWindow(hVertScroll,crt.right-SBW,SPLITWIDTH,SBW,

crt.bottom-SBW-SPLITWIDTH,TRUE);

} else {

MoveWindow(hVertScroll,crt.right-SBW,0,SBW,crt.bottom-SBW,TRUE);

}

if (bHorzSplit) {

MoveWindow(hHorzScroll,SPLITWIDTH,crt.bottom-SBW,

crt.right-SBW-SPLITWIDTH,SBW,TRUE);

} else {

MoveWindow(hHorzScroll,0,crt.bottom-SBW,crt.right-SBW,SBW,TRUE);

}

MoveWindow(hBtnSetting,crt.right-SBW,crt.bottom-SBW,SBW,SBW,TRUE);

if (nWrap) {

....

수평, 수직 스크롤 바를 작업 영역의 오른쪽과 아래쪽에 배치한다. bVertSplit, bHorzSplit 변수가 TRUE이면 스크롤 바 위, 왼쪽에 SPLITWIDTH만큼 여백을 남겨두고 그렇지 않으면 스크롤 바가 벽을 가득 채운다. 포맷팅 영역 frt에는 스크롤 바 영역이 제외되고 여기에 마진 영역까지 제외된다. 즉 frt는 뷰의 작업영역 중 차일드나 마진에 의해 가려지지 않은 영역만을 가진다.

표준 스크롤 바 대신 스크롤 바 컨트롤을 사용함으로써 스크롤 바 관리 정책을 약간 변경할 필요가 있다. 지금까지 수직 스크롤 바는 항상 보이게 하고 수평 스크롤 바는 자동 개행 옵션에 따라 보이거나 숨겼는데 이후부터는 자동 개행 여부에 상관없이 수평 스크롤 바를 항상 표시한다. 다만 자동 개행 상태일 때는 수평 스크롤 바를 사용 금지시켜 스크롤할 수 없게 할 것이다.

이렇게 정책을 바꾸는 이유는 자동 개행 옵션과는 상관없이 수평으로 편집창을 분할할 수 있어야 하고 그러자면 수평 스플릿 박스가 항상 화면에 보여야 하기 때문이다. 수평 스플릿 박스는 수평 스크롤 바 옆에 배치되는데 스크롤 바 없이 스플릿 박스만 있으면 보기에 좋지 않다. 수직 스크롤 바 아래에 약간의 여백이 있으므로 여기에 수평 스플릿 박스를 둘 수도 있지만 직관적이지 못하다.

이렇게 해도 기능적인 문제는 없지만 그림에서 보다시피 마진 아래쪽에 스플릿 박스만 덜렁 그려져 있는 모습이 얼마나 어색한가. 또한 이제 스크롤 바가 컨트롤이기 때문에 스크롤 바가 숨어 버리면 포맷팅 영역이 변경된다는 문제도 있다. 표준 스크롤 바는 작업 영역 바깥에 생성되므로 포맷팅 영역에는 영향을 주지 않지만 컨트롤은 그렇지가 못한 것이다. 수직으로 스크롤할 때마다 수평 스크롤 바가 있는지 없는지를 일일이 계산해야 한다는 부담도 있기 때문에 숨기는 대신 사용금지하는 정책을 선택했다. 수평 스크롤 바를 관리하는 SetWrap 함수를 다음과 같이 수정한다.

void CApiEditText::SetWrap(int aWrap)

{

nWrap=aWrap;

if (nWrap && RightWrap==0) {

EnableScrollBar(hHorzScroll,SB_CTL,ESB_DISABLE_BOTH);

xPos=0;

} else {

EnableScrollBar(hHorzScroll,SB_CTL,ESB_ENABLE_BOTH);

}

Invalidate(-1);

UpdateLineInfo();

UpdateScrollInfo();

SetCaret();

}

자동 개행 여부에 따라 수평 스크롤 바를 사용 금지 또는 허가한다. 표준 스크롤 바 대신 스크롤 바 컨트롤이 사용되었으므로 스크롤 바를 프로그래밍하는 모든 곳이 수정되어야 한다. Get(Set)ScrollInfo 함수의 두번째 인수를 SB_HORZ, SB_VERT 대신 SB_CTL로 변경하고 첫 번째 인수에 스크롤 바 컨트롤의 핸들을 주면 된다. UpdateScrollInfo를 다음처럼 수정한다.

void CApiEditText::UpdateScrollInfo()

{

....

SetScrollInfo(hWnd, SB_VERT, &si, TRUE);

SetScrollInfo(hVertScroll, SB_CTL, &si, TRUE);

if (si.nPage >= (unsigned)si.nMax) {

EnableWindow(hVertScroll,FALSE);

}

if (nWrap == 0 || RightWrap != 0) {

....

SetScrollInfo(hWnd, SB_HORZ, &si, TRUE);

SetScrollInfo(hHorzScroll, SB_CTL, &si, TRUE);

if (si.nPage >= (unsigned)si.nMax) {

EnableWindow(hHorzScroll,FALSE);

}

}

}

스크롤 바의 위치와 범위를 지정하는 대상이 표준 스크롤 바에서 스크롤 바 컨트롤로 바뀐 것 밖에는 차이가 없다. 여기서 SB_HORZ, SB_VERT 표준 스크롤 바에 대한 범위를 지정하지 않기 때문에 뷰에는 더 이상 표준 스크롤 바가 나타나지 않는다.

스크롤 바 범위를 설정한 후 페이지 크기가 범위보다 더 크면 스크롤 바를 아예 사용 금지한다. SetScrollInfo 함수에 SIF_DISABLENOSCROLL이라는 플래그가 있지만 위치값을 같이 지정할 때는 이 플래그가 제대로 동작하지 않는 것 같다. 또한 사용금지된 스크롤 바에 대해 SetScrollInfo나 SetScrollPos로 위치를 변경하면 다시 사용 허가 상태로 돌아와 버리는 문제가 있다. 그래서 범위 점검 후 직접 사용 금지 시켰다. 스크롤 바의 메시지를 처리하는 두 함수도 수정되는데 이 함수들은 좀 더 수정할 것이 많다.

void CApiEditText::OnHScroll(HWND hWnd, HWND hwndCtl, UINT code, int pos)

{

int xInc;

SCROLLINFO si;

POINT pt;

if (!IsWindowEnabled(hHorzScroll)) {

return;

}

xInc=0;

switch (code) {

....

case SB_THUMBTRACK:

si.cbSize=sizeof(SCROLLINFO);

si.fMask=SIF_TRACKPOS;

GetScrollInfo(hHorzScroll,SB_CTL,&si);

xInc=si.nTrackPos-xPos;

break;

default:

break;

}

xInc=max(-xPos, min(xInc, xMax-xPos));

xPos=xPos+xInc;

ScrollWindow(hWnd, -xInc, 0, &frt, &frt);

SetScrollPos(hHorzScroll, SB_CTL, xPos, TRUE);

GetXYFromOff(off,(int &)pt.x,(int &)pt.y);

pt.x-=xPos;

if (pt.x < MarginWidth) {

if (bHideCaret==FALSE) {

HideCaret(hWnd);

bHideCaret=TRUE;

}

} else {

ShowCaret(hWnd);

bHideCaret=FALSE;

}

// 스크롤된만큼 캐럿의 위치도 이동한다.

if (bHideCaret==FALSE) {

SetCaret(FALSE,FALSE);

}

}

void CApiEditText::OnVScroll(HWND hWnd, HWND hwndCtl, UINT code, int pos)

{

int yInc;

SCROLLINFO si;

int LinePerPage;

RECT srt;

if (!IsWindowEnabled(hVertScroll)) {

return;

}

LinePerPage=(frt.bottom/LineHeight)*LineHeight;

yInc=0;

switch (code) {

....

case SB_THUMBTRACK:

si.cbSize=sizeof(SCROLLINFO);

si.fMask=SIF_TRACKPOS;

GetScrollInfo(hVertScroll,SB_CTL,&si);

yInc=si.nTrackPos-yPos;

break;

default:

break;

}

yInc=max(-yPos, min(yInc, yMax-yPos-LinePerPage));

yInc=yInc-(yInc % LineHeight);

yPos=yPos+yInc;

// 포맷팅 영역과 마진 영역만 스크롤한다.

srt=frt;

srt.left=0;

ScrollWindow(hWnd, 0, -yInc, &srt,&srt);

SetScrollPos(hVertScroll, SB_CTL, yPos, TRUE);

SetCaret(FALSE,FALSE);

}

스크롤 바가 사용금지 상태이면 이 메시지를 처리할 필요없다. SetScrollPos 함수만 부르면 스크롤 바가 다시 활성화되어 버리기 때문에 이 조건 점검은 반드시 필요하다. 만약 그렇지 않으면 선택중에 커서가 작업영역 밖으로 벗어나기만 해도 즉시 활성화되어 버리는데 이때 스크롤 바의 범위는 0이므로 실제로 스크롤할 수도 없는데 스크롤 바가 활성화된다. 그래서 스크롤 바가 활성화되어 있을 때만 이 메시지를 처리한다. UpdateScrollInfo에서 활성화시켜 줄 때까지 이 두 함수는 아무것도 하지 않고 낮잠을 잔다.

수직 스크롤 시(OnVScroll) 스크롤 영역과 클리핑 영역을 정확하게 계산하여 수평 스크롤 바가 스크롤되지 않도록 해야 한다. 스크롤할 영역은 포맷팅 영역에서 마진 영역을 포함시킨 영역이다. 즉 작업영역에서 스크롤 바 컨트롤이 차지하고 있는 영역을 제외하고 모두 스크롤된다. 스크롤 영역 srt는 다음과 같이 계산되며 굵은 사각형안이 스크롤될 영역이다.

표준 스크롤 바는 캐럿까지 같이 스크롤하지만 스크롤 바 컨트롤은 캐럿을 스크롤 대상에서 제외하므로 스크롤 후에 SetCaret 함수를 호출하여 캐럿 위치를 다시 계산해야 한다.

OnHScroll 함수는 원래 클리핑 영역을 사용하고 있었는데 추가로 스크롤 영역도 지정해야 한다. 포맷팅 영역을 스크롤 영역으로 지정함으로써 수직 스크롤 바가 스크롤되지 않게 했다. 수평 스크롤시 캐럿이 마진안으로 들어가면 캐럿을 숨기는 기능이 있었는데 이 코드도 조금 수정되었다. 숨김 처리를 위해 캐럿의 좌표가 마진 안에 있는지 아닌지를 조사해야 하는데 스크롤에 따라 캐럿이 이동되지 않으므로 숨겨져 있는 상태에서는 GetCaretPos로 정확한 위치를 조사할 수 없으며 그래서 GetXYFromOff로 좌표를 조사한 후 현재 스크롤 값을 빼서 직접 위치를 구했다.

그외 표준 스크롤 바를 다루던 모든 부분을 수정해야 한다. PgUp, PgDn으로 페이지 단위로 이동할 때, 휠 마우스로 스크롤할 때, 그리고 SetCaret에 의해 캐럿이 있는 곳으로 강제 스크롤 될 때 세 군데가 더 있다. SB_HORZ, SB_VERT를 모두 SB_CTL로 변경하고 스크롤 영역에서 스크롤 바 컨트롤의 영역을 뺀다.

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

{

....

case VK_PRIOR:

....

SetScrollPos(hVertScroll, SB_CTL, yPos, TRUE);

case VK_NEXT:

....

SetScrollPos(hVertScroll, SB_CTL, yPos, TRUE);

void CApiEditText::OnMouseWheel(HWND hWnd, WPARAM wParam, LPARAM lParam)

{

RECT srt;

....

LinePerPage=(frt.bottom/LineHeight)*LineHeight;

yInc=LineHeight*nScroll;

yInc=max(-yPos, min(yInc, yMax-yPos-LinePerPage));

yInc=yInc-(yInc % LineHeight);

yPos=yPos+yInc;

srt=frt;

srt.left=0;

ScrollWindow(hWnd, 0, -yInc, &srt, &srt);

if (IsWindowEnabled(hVertScroll)) {

SetScrollPos(hVertScroll, SB_CTL, yPos, TRUE);

}

SetCaret(FALSE,FALSE);

}

void CApiEditText::SetCaret(BOOL bUpdatePrevX/*=TRUE*/, BOOL bScrollToCaret/*=TRUE*/)

{

....

if (bScroll == TRUE) {

if (IsWindowEnabled(hHorzScroll)) {

SetScrollPos(hHorzScroll, SB_CTL, xPos, TRUE);

}

if (IsWindowEnabled(hVertScroll)) {

SetScrollPos(hVertScroll, SB_CTL, yPos, TRUE);

}

Invalidate(-1);

}

}

....

휠 마우스로 스크롤 할 때도 스크롤 영역과 클리핑 영역을 잘 계산해야 하며 SetCaret은 수평 스크롤 바가 활성화되어 있을 때만 위치를 갱신한다. 여기까지 작업한 후 실행해 보면 스크롤 바 위와 옆에 조그만 여백이 나타날 것이다.

스크롤 바가 컨트롤로 바뀌었지만 수정전과 마찬가지로 스크롤될 것이다. 저 조그만 여백을 만들기 위해 표준 스크롤 바 대신 스크롤 바 컨트롤을 사용했다.

나. 사용 금지된 스크롤 바

수평 스플릿 박스 배치를 위해 수평 스크롤 바를 항상 보이도록 정책을 변경했으며 자동 개행시는 수평 스크롤 바를 숨기지 않고 사용 금지만 시켰다. 그러나 이렇게 되면 몇가지 문제가 발생하는데 사용 금지된 스크롤 바 위에서 마우스 커서가 I자 모양이 되며 이 상태에서 마우스를 클릭하면 포맷팅 영역을 클릭한 것처럼 동작한다.

왜 이렇게 되는가 하면 사용 금지된 차일드는 자신에게 전달되는 메시지를 직접 처리하지 않고 부모에게 다시 보내기 때문이다. WM_LBUTTONDOWN, WM_SETCURSOR가 스크롤 바의 부모인 ApiEditText로 전달되며 뷰는 사용자가 포맷팅 영역을 누른 것으로 알고 잘못 동작하는 것이다. 스크롤 바를 아예 숨겨 버린다면 문제가 없지만 이렇게 할 수 없음은 앞에서 이미 설명했었다. 이 문제를 해결하는 방법도 여러 가지가 있다.

첫 번째 방법은 스크롤 바를 뷰의 차일드로 생성하지 말고 프레임의 차일드로 생성하는 것이다. 이렇게 되면 스크롤 바 컨트롤이 뷰의 작업 영역에 배치되는 것이 아니므로 뷰는 스크롤할 때 클리핑 처리를 할 필요도 없고 사용 금지된 컨트롤에 대해 신경쓸 필요도 없다. 뿐만 아니라 스플릿 박스를 분할 주체인 프레임이 가지므로 뷰는 창 분할에 대한 UI를 제공하지 않아도 되는 추가적인 이점이 있다.

대신 사용자의 스크롤 처리를 프레임이 대신 받아 뷰에게 전달하도록 구조를 조금 바꾸어야 할 필요는 있지만 방식을 조금 바꾸는 것일 뿐 문제가 될 정도는 아니다. MFC가 이 방식대로 뷰와 프레임을 관리한다. 그러나 이 방식은 아주 치명적인 약점이 하나 있는데 창이 분할되었을 때 각 분할 뷰에 스크롤 바가 생성되는 것이 아니므로 분할 뷰가 서로 다른 스크롤 상태를 가질 수 없다는 점이다. 다음은 비주얼 스튜디오 6.0의 편집기를 수평으로 분할해 놓은 모습이다.

보다시피 뷰는 두 개로 분할되었지만 수직 스크롤 바는 하나밖에 없다. 그래서 이 두 뷰는 수직으로 다른 위치를 보여주지 못하며 수평 방향으로만 서로 다른 스크롤 상태를 가질 수 있다. 이렇게 되면 수평 분할로는 문서의 다른 부분을 볼 수 없으며 분할의 의미가 없는 것과 마찬가지다. 비주얼 스튜디오뿐만 아니라 MFC 프레임워크의 자동화된 분할 기능을 사용하는 응용 프로그램들은 공통적으로 이런 한계점을 가지고 있다. ApiEdit는 분할된 뷰가 완전히 독립적으로 움직일 수 있도록 하기 위해 이 방식을 채택하지 않았다.

두 번째 방법은 수평 스크롤 바를 사용 금지하지 말고 항상 보이도록 하되 범위를 0으로 만들어 스크롤할 수 없게 하고 OnHScroll에서 스크롤 요청을 거부하는것이다. 충분히 가능한 방법이고 기능상의 문제는 없지만 스크롤 바가 마치 사용 가능한 것처럼 보여 직관적이지 못하다는 것이 불만이다. ApiEdit는 두 방법 모두 채택하지 않으며 현재 구조를 고수하면서 문제만 해결하는 정면 돌파를 하기로 했다. SetCaret에는 수평 스크롤 바가 사용 금지되었을 때 위치 갱신을 하지 않게 이미 조치했으며 다음 두 메시지에서만 사용 금지된 스크롤 바를 관리하면 된다.

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

{

RECT crt;

GetClientRect(hWnd,&crt);

GetCursorPos(&pt);

ScreenToClient(hWnd,&pt);

if (pt.x != x || pt.y != y) {

return;

}

// 사용금지된 스크롤 바 위에서의 클릭은 무시한다.

if (y > crt.bottom-SBW || x > crt.right-SBW) {

return;

}

....

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

{

RECT crt;

GetClientRect(hWnd,&crt);

....

// 사용금지된 스크롤 바 위에서의 화살표 커서를 표시한다.

if (pt.y > crt.bottom-SBW || pt.x > crt.right-SBW) {

SetCursor(LoadCursor(NULL,IDC_ARROW));

return TRUE;

}

pt.x += xPos;

....

스크롤 바가 사용금지되어 있으면 부모인 뷰가 대신 메시지를 받는데 이때 마우스를 누른 영역이 사용금지된 스크롤 바 컨트롤의 영역이면 이 메시지를 완전히 무시한다. 스크롤 바 컨트롤의 사용 금지 여부는 볼 필요없고 마우스를 누른 좌표만 비교해 보면 스크롤 바 컨트롤 위에서 클릭했는지 알 수 있다. 사실 스크롤 바가 사용 가능한 상태에서는 스크롤 바가 메시지를 받으므로 뷰의 메시지 처리 함수가 호출되지도 않는다.

OnSetCursor는 스크롤 바 컨트롤의 영역에 커서가 있을 때 화살표 모양의 커서를 강제로 보이도록 했다. 마찬가지로 스크롤 바 컨트롤이 사용 가능한 상태에서는 스크롤 바가 스스로 WM_SETCURSOR 메시지를 처리하므로 뷰의 이 함수가 호출되지 않는다. 조금 억지스러운 면이 있기는 하지만 어쨌거나 문제는 해결되었다.

다. 스플릿 박스

스크롤 바 위에 스플릿 박스를 위한 여백을 힘들게 만들었으므로 이제 여기에 스플릿 박스를 예쁘게 그리기만 하면 된다. 조그만 박스 모양이고 그 자체가 기능을 갖는 것은 아니지만 이 부분을 드래그하면 창이 분할된다는 것을 직관적으로 설명하는 역할을 한다. 뷰의 OnPaint에서 스플릿 박스를 직접 그린다.

void CApiEditText::OnPaint(HWND hWnd)

{

....

RECT crt,srt;

hdc=BeginPaint(hWnd,&ps);

GetClientRect(hWnd,&crt);

....

// 스플릿 박스를 그린다.

if (bVertSplit) {

SetRect(&srt,crt.right-SBW,crt.top,crt.right,crt.top+SPLITWIDTH);

DrawFrameControl(hdc,&srt,DFC_BUTTON,DFCS_BUTTONPUSH);

}

if (bHorzSplit) {

SetRect(&srt,crt.left,crt.bottom-SBW,crt.left+SPLITWIDTH,crt.bottom);

DrawFrameControl(hdc,&srt,DFC_BUTTON,DFCS_BUTTONPUSH);

}

EndPaint(hWnd,&ps);

}

텍스트와 마진을 모두 출력한 후에 스크롤 바 위와 왼쪽 여백의 빈 자리에 스플릿 박스를 그렸다. DrawFrameControl 함수로 버튼 모양을 출력하기만 하면 된다. 단, bVertSplit, bHorzSplit이 FALSE일 때는 이 여백이 아예 없으므로 스플릿 박스를 그릴 필요가 없다. 이 영역에 마우스 커서가 위치하면 커서 모양을 바꾸어 창 분할을 할 수 있다는 것을 명확하게 보여 주기 위해 OnSetCursor에서 커서 모양을 변경한다.

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

{

POINT pt;

RECT crt;

GetClientRect(hWnd,&crt);

GetCursorPos(&pt);

ScreenToClient(hWnd,&pt);

if (codeHitTest==HTCLIENT) {

if (pt.x < MarginWidth && pt.y < crt.bottom-SBW) {

SetCursor(CApiEdit::hCMargin);

return TRUE;

}

// 수직 스플릿 박스의 커서

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

SetCursor(LoadCursor(NULL,IDC_SIZENS));

return TRUE;

}

// 수평 스클릿 박스의 커서

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

SetCursor(LoadCursor(NULL,IDC_SIZEWE));

return TRUE;

}

// 사용금지된 스크롤 바 위에서의 화살표 커서를 표시한다.

if (pt.y > crt.bottom-SBW || pt.x > crt.right-SBW) {

SetCursor(LoadCursor(NULL,IDC_ARROW));

return TRUE;

}

....

화면 분할이 가능한 상태이고 커서 위치가 스플릿 박스 위에 있을 때 적당한 모양의 커서로 바꾸었다. 수평 스크롤 바의 높이만큼은 이제 더 이상 마진이 아니므로 이 영역에서는 마진 커서를 보여주지 않는다. 스톡 커서중에 크기 변경 커서가 있으므로 별도의 커서 리소스를 만들 필요없이 스톡 커서를 사용하였다.

스플릿 박스가 그려졌고 그 위에서 커서 모양이 변경되므로 사용자들은 여기를 드래그하면 창이 분할될 것이라는 것을 쉽게 알 수 있을 것이다.

라. 화면 분할 요청

뷰를 분할하는 주체는 뷰를 거느리고 있는 프레임이다. 하지만 사용자로부터 분할 명령을 받는 유저 인터페이스인 스플릿 박스는 뷰가 가지므로 뷰가 분할 명령을 받아서 프레임에게 요청해야 한다. 수직 스크롤 바의 위, 수평 스크롤 바의 왼쪽에 있는 스플릿 박스를 드래그하면 어디쯤에 분할될 것이라는 것을 표시하는 반전 막대를 보여 주고 마우스 버튼을 놓으면 프레임에게 분할을 요청한다.

분할의 방향은 수평, 수직 두 가지가 있다. 수직 스플릿 박스를 드래그하면 수직으로 분할하고 수평 스플릿 박스를 드래그하면 수평으로 분할한다. 방향에 따라 분할 방법 및 반전막대를 그리는 방법이 다르므로 각 분할 방향을 ApiEdit.h에 열거형으로 선언한다. 1이면 수직으로 분할하는 것이고 2면 수평으로 분할하는 것이다.

enum { AESPLIT_VERT=1, AESPLIT_HORZ };

#define VGAP 6

VGAP은 뷰간의 간격값인데 6으로 정의한다. 6픽셀이면 굉장이 두꺼울 것 같지만 바깥의 2픽셀은 장식을 위한 선이 그려지기 때문에 막상 그려놓고 보면 적당한 두께로 보일 것이다. 프레임은 분할 요청중에 분할 위치를 표시하기 위해 반전막대를 그린다. 이미 2개의 뷰로 분할된 상태에서 4분할할 때는 분할된 뷰 위쪽에 반전막대가 그려져야 하므로 반전막대는 뷰가 아닌 프레임이 직접 그려야 한다.

뷰는 자신의 작업영역을 반전시킬 수는 있지만 형제의 작업영역에까지 손댈 수는 없기 때문이다. CApiEdit 프레임에 다음 멤버 함수를 추가한다.

// SplitType 방향의 pos위치에 분할 반전 막대를 그린다.

void CApiEdit::DrawSplitBar(int SplitType,int pos)

{

HDC hdc;

RECT crt;

DWORD dwStyle;

HBRUSH hSplitBrush;

HBRUSH OldBrush;

static WORD SplitPattern[]={0x5555,0xaaaa,0x5555,0xaaaa,

0x5555,0xaaaa,0x5555,0xaaaa};

HBITMAP hPattern;

// 반전 막대를 그리기 위한 회색 패턴 브러시

hPattern=CreateBitmap(8,8,1,1,SplitPattern);

hSplitBrush=CreatePatternBrush(hPattern);

DeleteObject(hPattern);

// WS_CLIPCHILDREN 스타일을 잠시 없애고 반전 막대를 그린다.

GetClientRect(hWnd,&crt);

dwStyle=GetWindowLong(hWnd,GWL_STYLE);

SetWindowLong(hWnd,GWL_STYLE,dwStyle & ~WS_CLIPCHILDREN);

hdc=GetDC(hWnd);

OldBrush=(HBRUSH)SelectObject(hdc,hSplitBrush);

if (SplitType==AESPLIT_VERT) {

PatBlt(hdc,crt.left,crt.top+pos,crt.right,4,PATINVERT);

} else {

PatBlt(hdc,crt.left+pos,crt.top,4,crt.bottom,PATINVERT);

}

SelectObject(hdc,OldBrush);

DeleteObject(hSplitBrush);

ReleaseDC(hWnd,hdc);

SetWindowLong(hWnd,GWL_STYLE,dwStyle);

}

인수로 전달받은 SplitType 방향으로 pos 위치에 반전 막대를 그린다. XOR로 그리기 때문에 같은 위치에 대해 이 함수를 두 번 호출하면 이미 그려진 반전 막대가 지워진다. 프레임은 WS_CLIPCHILDREN 스타일을 가지고 있는데 이 스타일을 잠시 해제해야 차일드위에 반전 막대를 그릴 수 있다.

이 방법이 마음에 들지 않는다면 윈도우 DC를 사용할 수도 있고 전체 화면 DC를 사용할 수도 있는데 이 경우 반전 막대가 그려질 작업 영역 좌표를 정확하게 계산해야 한다. 사용하는 DC에 따라 항상 위(Always On Top) 속성을 가지는 윈도우가 위에 있을 때 반전 막대가 이 윈도우 위에 그려질 것인가, 밑에 그려질 것인가의 차이가 있다. 아니면 hdc=GetDCEx( hWnd, NULL, DCX_PARENTCLIP);으로 DC를 구해 DC에만 차일드 영역 클리핑 속성을 잠시 무시할 수도 있다. 아뭏든 그냥 GetDC로 DC를 얻어서는 차일드 위쪽에 반전 막대를 그리지 못한다.

반전 막대를 예쁘게 그리기 위해 회색의 패턴 브러시를 매번 생성하여 사용한다. 이 브러시를 스태틱 멤버로 포함시켜 놓고 LoadAeResource 함수에서 미리 생성해 놓을 수도 있으나 사용자의 드래그 동작이 빠르지 않으므로 함수내에서 만들고 삭제했다. 반전 막대의 폭은 4픽셀로 고정되어 있는데 뷰간의 간격인 VGAP(6픽셀)으로 하는 것도 좋으나 너무 두꺼우면 예쁘지 않다.

프레임은 분할 중에 반전막대를 그리고 마우스 버튼을 놓으면 실제 분할을 하지만 분할이 되기 전까지의 모든 동작은 뷰가 직접 해야 한다. 드래그를 시작하고 스플릿 박스를 드래그중인 동안 반전 막대를 같이 이동시키는 것은 모두 뷰가 해야 할 일이다. 드래그 처리를 위해 다음 두 개의 멤버 변수와 세 개의 멤버 함수를 선언하고 InitView에서 멤버 변수는 모두 0으로 초기화한다.

class CApiEditText : public CWindow

{

protected:

....

int iDrag;

int OldSplit;

public:

....

virtual BOOL StartSplit(HWND hWnd,BOOL fDoubleClick,int x,int y);

virtual BOOL Spliting(HWND hWnd,int x,int y);

virtual BOOL EndSplit(HWND hWnd,int x,int y);

};

void CApiEditText::InitView()

{

....

iDrag=0;

OldSplit=0;

Invalidate(-1);

}

iDrag는 분할 방향이며 OldSplit은 분할중 이전 반전 막대의 위치를 기억한다. 마우스 왼쪽 버튼으로 스플릿 박스를 누르면 분할을 시작하되 OnLButtonDown에서 직접 이 처리를 하지 않고 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) {

iDrag=AESPLIT_VERT;

}

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

iDrag=AESPLIT_HORZ;

}

if (iDrag) {

SetCapture(hWnd);

bCapture=TRUE;

OldSplit=0;

pFrame->DrawSplitBar(iDrag,OldSplit);

return TRUE;

}

return FALSE;

}

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

{

....

if (pt.x != x || pt.y != y) {

return;

}

// 스플릿 박스 위면 창 분할을 시작한다.

if (StartSplit(hWnd,fDoubleClick,x,y)) {

return;

}

....

스플릿 박스 위에서 마우스를 눌렀는지 점검해 보되 어떤 스플릿 박스인지에 따라 iDrag에 방향을 대입한다. 만약 스플릿 박스가 아닌 다른 곳을 눌렀다면 iDrag는 0의 값을 가지며 작업 영역에서의 입력으로 해석된다. iDrag가 0이 아니면 즉, 어느 방향으로든지 스플릿 박스를 눌렀으면 커서를 캡처하고 OldSplit에 0을 대입하여 제일 위(또는 제일 왼쪽)에서부터 분할이 시작되었음을 기억해 놓는다. 분할 명령 입력이 시작되었으므로 프레임의 DrawSplitBar 함수를 호출하여 최초 위치에 반전 막대를 출력하였다.

포맷팅 영역에서 마우스를 누른 것이 아니므로 더 이상의 처리(캐럿 이동, 선택 시작)는 할 필요가 없으며 return한다. 이후의 처리는 OnMouseMove에서 담당한다. iDrag가 0이 아닌 상태에서 마우스를 이동하면 반전막대를 같이 이동시킨다. 이 동작도 뷰의 타입과 상관없이 동일하므로 재활용을 위해 Spliting이라는 별도의 함수에 코드를 작성했다.

BOOL CApiEditText::Spliting(HWND hWnd,int x,int y)

{

int tx,ty;

RECT FrameRect;

GetClientRect(pFrame->hWnd,&FrameRect);

if (iDrag == AESPLIT_VERT) {

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

if (OldSplit != ty) {

pFrame->DrawSplitBar(iDrag,OldSplit);

OldSplit=ty;

pFrame->DrawSplitBar(iDrag,OldSplit);

}

return TRUE;

}

if (iDrag ==AESPLIT_HORZ) {

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

if (OldSplit != tx) {

pFrame->DrawSplitBar(iDrag,OldSplit);

OldSplit=tx;

pFrame->DrawSplitBar(iDrag,OldSplit);

}

return TRUE;

}

return FALSE;

}

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

{

if (bCapture == FALSE) {

return;

}

// 창 분할중이면 분할을 처리한다.

if (Spliting(hWnd,x,y)) {

return;

}

....

반전 막대의 현재 위치인 OldSplit 좌표에 DrawSplitBar로 다시 반전 막대를 그려 원래 그려져 있던 반전 막대는 지운다. DrawSplitBar 함수는 XOR 방식으로 반전 막대를 그리기 때문에 같은 위치에 두 번 출력하면 지우는 것이다. 그리고 OldSplit을 현재 커서 좌표로 대입한 후 다시 반전 막대를 그린다. 단 현재 커서 위치는 프레임의 작업 영역 안쪽으로 제한하여 반전 막대가 프레임 바깥을 벗어나지는 않도록 하였다. 이런 식으로 반전 막대는 마우스 커서를 졸졸 따라다니며 마우스 버튼을 놓을 때 프레임에게 분할을 요청한다.

BOOL CApiEditText::EndSplit(HWND hWnd,int x,int y)

{

int Ratio;

RECT crt;

GetClientRect(hWnd,&crt);

if (iDrag) {

pFrame->DrawSplitBar(iDrag,OldSplit);

if (iDrag==AESPLIT_VERT) {

Ratio=y*10000/(crt.bottom-crt.top);

} else {

Ratio=x*10000/(crt.right-crt.left);

}

if (Ratio > 500 && Ratio < 9500) {

pFrame->SplitView(iDrag,Ratio);

}

iDrag=0;

return TRUE;

}

return FALSE;

}

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

{

....

// 창 분할중이었으면 분할을 종료한다.

if (EndSplit(hWnd,x,y)) {

return;

}

bControl=((GetKeyState(VK_CONTROL) & 0x8000) != 0);

....

DrawSplitBar 함수를 다시 호출하여 OldSplit에 출력되어 있는 반전 막대는 일단 지운다. 분할 방향에 따라 분할 비율을 결정하는데 작업 영역의 높이(또는 폭)에 대해 마우스 커서가 어디쯤 와 있는가로 비율을 계산한다. 비율에 10000을 곱해 만분율을 구했는데 소수점 이하 두자리까지 유효한 백분율이라고 생각해도 무방하다. 실수는 느리기 때문에 적당한 수준의 정수값을 사용한다. 분할 상태를 비율로 관리하기 때문에 분할된 상태에서 윈도우 크기를 변경할 때 분할창의 크기가 유지되지 않고 비율만 유지된다.

분할 비율이 너무 작거나 크면 분할은 취소된다. 최소한 5%~95% 범위에 있을 때만 창을 분할하는데 이는 분할을 취소할 수 있는 장치이다. 실수로 스플릿 박스를 드래그했거나 아니면 이미 분할된 창을 취소할 때 반전막대를 드래그하여 위쪽이나 아래쪽으로 드래그해 버리면 분할을 취소한다. 그래서 별도의 분할 취소 유저 인터페이스는 제공되지 않는다. 분할 비율이 적정 범위에 있을 때는 프레임의 SplitView 함수를 호출하여 분할을 요청한다. 결국 뷰가 하는 일은 실제로 뷰를 분할하는 것이 아니라 사용자로부터 분할 명령을 받아서 프레임에게 전달하는 것 뿐이다.

마. 편집창 분할

프레임은 뷰의 분할은 물론이고 분할 취소, 분할 비율 조정, 분할 후 각 뷰의 분할 가능성 관리, 분할된 뷰의 배치 등 여러 가지 일을 한다. CApiEdit 프레임에 창분할 관련 멤버 변수와 함수를 선언한다.

class CApiEdit : public CWindow

{

private:

....

int iDrag;

POINT SplitPt;

int OldSplitX,OldSplitY;

DWORD SplitFlag;

public:

....

int VertRatio;

int HorzRatio;

....

void SplitView(int SplitType, int Ratio);

BOOL IsInDBCS(int nPos);

void CloneView(CApiEditText *pDest, CApiEditText *pSrc,int SplitType);

void AdjustSplitable();

void UnSplitView(int SplitType);

void ChangeActiveView(CApiEditText *pAe,int Who);

void UpdateViews(CApiEditText *pView,int nPos,int nCount);

void EnableSplit(DWORD Flag);

분할 상태는 프레임의 상태(=컨트롤의 상태)이기 때문에 별도의 멤버 변수에 저장해야 한다. VertRatio, HorzRatio는 수직, 수평 분할 비율이며 만분율인데 이 값이 0이면 분할되어 있지 않은 것이고 5000이면 절반으로 분할되어 있는 상태이다. 프레임의 분할 상태는 편집 정보 저장에서 참조하기 때문에 public 영역에 선언했다. iDrag와 OldSplitX, OldSplitY는 뷰의 경우와 동일하되 두 방향으로 동시에 드래그할 수 있기 때문에 Old값이 두 개 필요하다는 점만 다르다. SplitFlag는 분할 가능한 방향을 지시하는 컨트롤 전역 설정 값이다. 생성자에서 이 변수들을 다음과 같이 초기화한다.

CApiEdit::CApiEdit()

{

....

VertRatio=0;

HorzRatio=0;

iDrag=0;

SplitFlag=AESPLIT_VERT | AESPLIT_HORZ;

}

실제로 컨트롤의 작업 영역을 분할하는 함수는 SplitView이며 뷰의 OnLButtonUp에서 호출한다. 인수로 분할 방향과 분할 비율이 전달되는데 이는 최초 사용자가 어떤 스플릿 박스를 드래그했는지와 어디쯤에서 마우스 버튼을 놓았는지에 따라 달라질 것이다. 예를 들어 수직 스플릿 박스를 드래그하여 절반 위치에서 버튼을 놓았다면 SplitType은 AESPLIT_VERT가 되며 Ratio는 5000이 될 것이다.

// SplitType 방향으로 Ratio 비율만큼 창을 분할한다.

void CApiEdit::SplitView(int SplitType, int Ratio)

{

// 수직 분할

if (SplitType == AESPLIT_VERT) {

// 분할되지 않았으면 2분할한다.

if (arView[1]==NULL) {

arView[1]=CreateView(arView[0]->ViewType);

CloneView(arView[1],arView[0],SplitType);

// 2분할이면 4분할한다.

} else {

arView[2]=CreateView(arView[0]->ViewType);

CloneView(arView[2],arView[0],SplitType);

arView[3]=CreateView(arView[1]->ViewType);

CloneView(arView[3],arView[1],SplitType);

}

VertRatio=Ratio;

// 수평 분할

} else {

if (arView[1]==NULL) {

arView[1]=CreateView(arView[0]->ViewType);

CloneView(arView[1],arView[0],SplitType);

} else {

arView[2]=arView[1];

arView[1]=CreateView(arView[0]->ViewType);

CloneView(arView[1],arView[0],SplitType);

arView[3]=CreateView(arView[2]->ViewType);

CloneView(arView[3],arView[2],SplitType);

}

HorzRatio=Ratio;

}

SendMessage(hWnd,WM_SIZE,0,0);

InvalidateRect(hWnd,NULL,TRUE);

AdjustSplitable();

}

이 함수가 프레임을 어떻게 분할할 것인가는 현재 분할 상태가 어떤가에 따라 달라지며 현재 분할 상태는 arView[1]을 읽어 보면 알 수 있다. arView[1]이 NULL이면 분할되어 있지 않은 것이고 NULL이 아니면 2개로 이미 분할되어 있는 것이다. 분할되어 있지 않은 상태에서 분할 명령을 받았으면 방향에 따라 뷰 하나를 더 생성하면 되고 이미 분할되어 있다면 두 개의 뷰를 새로 만들어야 한다.

분할되어 있는 상태에서 수직 분할 명령을 받았다면 기존 분할은 수평이라는 것을 쉽게 유추할 수 있다. ApiEdit는 최대 4분할까지만 가능하며 수평 분할된 상태에서 다시 수평 분할 명령은 올 수가 없고 마찬가지로 수직 분할된 상태에서는 다시 수직으로 분할하지 못하기 때문이다. 4분할 된 상태에서는 어떤 분할 명령도 오지 못한다. SplitView의 분할 코드는 다음 그림처럼 동작한다.

분할되지 않은 상태에서 수직으로 분할하는 코드를 분석해 보자. CreateView로 기존 0번 뷰와 같은 타입의 뷰를 생성하여 arView[1]에 그 포인터를 대입한다. 그리고 0번 뷰의 속성을 1번 뷰로 복사하고 VertRatio에 분할 비율을 대입하면 된다. 속성을 복제할 때는 CloneView 함수를 사용하는데 잠시 후 작성할 것이다. 이렇게 뷰를 생성해 놓기만 하면 뷰를 배치하는 일은 OnSize에서 하며 그림의 오른쪽 위와 같은 상태가 된다. 수평으로 2분할할때도 동일하다.

다음은 수평 2분할(그림 왼쪽 아래) 상태에서 4분할하는 코드를 보자. 0번 뷰를 복사하여 2번 뷰를 만들고 1번 뷰를 복사하여 3번 뷰를 만들면 된다. 바로 위에 있는 뷰를 복사하여 아래쪽에 새 뷰를 만들면 된다. 수직 2분할 상태에서 4분할할 때는 조금 복잡한데 뷰의 순서를 약간 조정해야 한다.

0번과 1번 뷰가 아래 위로 배치되어 있는데 0번을 왼쪽으로 복제해서 2번을 만들고 1번을 복제해서 3번을 만들면 아래 그림처럼 되어 버리는데 이렇게 하면 안된다. arView[1]을 그대로 대입하여 arView[2]에 대피시켜 놓고 0번을 복제해서 1번을 다시 만들고 대피된 2번을 복제해서 3번을 만들어야 한다. arView 배열에 기억된 값은 뷰의 포인터이므로 특별한 처리없이 포인터를 바로 대입하는 것이 가능하다.

이렇게 해야 뷰의 번호가 항상 좌에서 우로, 위에서 아래로 흐르도록 유지되는데 뷰의 순서에 대해 일종의 정규화(Normalize)를 하는 것이다. 뷰의 순서를 일정하게 유지해야 뷰간의 포커스 전환이 자연스럽고 뷰를 취급하는 모든 함수들의 동작이 간단해진다. 다음 함수는 분할 후 뷰의 스플릿 박스를 관리하며 SplitView 함수는 뷰를 분할한 직후에 이 함수를 호출한다.

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

void CApiEdit::AdjustSplitable()

{

int i;

if (arView[1]==NULL) {

arView[0]->SetHorzSplit(TRUE);

arView[0]->SetVertSplit(TRUE);

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

if (VertRatio) {

arView[0]->SetHorzSplit(TRUE);

arView[0]->SetVertSplit(FALSE);

arView[1]->SetHorzSplit(TRUE);

arView[1]->SetVertSplit(FALSE);

} else {

arView[0]->SetHorzSplit(FALSE);

arView[0]->SetVertSplit(TRUE);

arView[1]->SetHorzSplit(FALSE);

arView[1]->SetVertSplit(TRUE);

}

} else {

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

arView[i]->SetHorzSplit(FALSE);

arView[i]->SetVertSplit(FALSE);

}

}

}

코드는 상식적으로 쉽게 이해가 될 것이다. 분할되어 있지 않으면 뷰는 양방향 모두 분할 가능하지만 분할되어 있으면 이미 분할된 방향으로는 분할을 금지한다. 예를 들어 수평으로 분할되어 있다면 이 뷰는 더 이상 수평으로 분할할 수 없으며 마찬가지로 수직으로 분할되어 있다면 수직 분할이 금지된다. 4분할되어 있는 상황이면 양쪽 모두 분할 금지된다. 각 뷰의 분할 가능성은 SetHorzSplit, SetVertSplit 함수로 제어할 수 있다. 뷰는 이 함수가 호출되었을 때 인수값에 따라 스크롤 바 위나 왼쪽의 스플릿 박스를 보여 주거나 숨김으로써 분할 가능성을 통제한다. 스플릿 박스가 없으면 최초 분할 시작을 할 수 없으므로 해당 방향으로는 분할할 수 없다.

분할된 방향으로 다시 분할을 허용하지 않기 때문에 최대 4분할밖에 지원을 하지 못하는 것이다. 만약 9분할이나 그 이상도 가능하게 하고 싶다면 이 함수가 좀 더 복잡해질 것이고 그외 뷰를 관리하는 모든 함수의 논리가 훨씬 더 정교해져야 할 것이다. 프레임/뷰로 객체가 나누어져 있는 구조에서 4분할 이상까지 지원하고자 한다면 굳이 못할 것도 없지만 복잡도에 비해 실용성이 크게 떨어지므로 ApiEdit는 그 이상의 분할은 지원하지 않는다. 코드가 복잡해지는 것도 문제가 되지만 막상 9분할 또는 16분할을 지원한다고 했을 때 이 프로그램을 사용하는 사람도 어지간히 헷갈려서 정신이 없을 것이다.

바. 뷰의 복제

새로 만들어진 뷰는 기존 뷰의 속성 중 일부를 복제해야 한다. 가령 기존 뷰가 자동 개행 상태였다면 분할되어 새로 만들어지는 뷰도 자동 개행 상태로 생성되는 것이 좋고 줄간이나 글꼴, 보기 상태, 색상 등도 가급적이면 일치시키는 것이 좋을 것이다. 이런 뷰의 복제 작업은 CloneView라는 함수가 담당하는데 함수 이름에서 알 수 있듯이 똑같은 속성을 가지는 뷰를 만든다.

SplitView 함수는 CreateView로 새로운 뷰를 만들면서 동시에 이 함수를 호출하여 뷰의 속성을 똑같이 복제하여 쌍둥이 동생을 만든다. 코드는 다음과 같으며 다소 길이가 긴 편인데 모든 속성을 한꺼번에 대입할 수는 없고 선별적으로 복제를 해야 하는데다 복제 시간을 짧게 하기 위해 복제 순서에도 신경을 써야 하기 때문이다.

// nPos가 DBCS 문자의 뒷바이트인지를 점검한다.

BOOL CApiEdit::IsInDBCS(int nPos)

{

int toff;

toff=max(0,nPos-32);

for (;toff < nPos;) {

if (IsDBCS(toff)) {

toff+=2;

} else {

toff++;

}

}

return (toff!=nPos);

}

// 뷰를 복제한다.

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

{

LOGFONT logfont;

int ViewFirstLine, ViewFirstOff,pr,pc;

// 글꼴 관련 속성 복사

pDest->LineRatio=pSrc->LineRatio;

pDest->SetWrap(pSrc->nWrap);

pDest->bNoFirstSpace=pSrc->bNoFirstSpace;

pDest->TabWidth=pSrc->TabWidth;

pDest->RightWrap=pSrc->RightWrap;

pSrc->GetFont(&logfont);

pDest->SetFont(&logfont);

// 보이기 관련 속성 복사

pDest->MarginWidth=pSrc->MarginWidth;

pDest->bShowLineNum=pSrc->bShowLineNum;

pDest->bShowTab=pSrc->bShowTab;

pDest->bShowEnter=pSrc->bShowEnter;

pDest->bShowSpace=pSrc->bShowSpace;

pDest->ShowTabType=pSrc->ShowTabType;

pDest->ShowEnterType=pSrc->ShowEnterType;

pDest->ShowSpaceType=pSrc->ShowSpaceType;

pDest->ColMark=pSrc->ColMark;

// 분석기 지정

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

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

// 편집 위치 복사. 헥사 뷰에서 텍스트 뷰로 복사할 때는 DBCS 경계에 걸치지 않도록 조정한다.

if (pSrc->ViewType==HEXA_VIEW && pDest->ViewType==TEXT_VIEW && IsInDBCS(pSrc->off)) {

pDest->off=GetPrevOff(pSrc->off);

} else {

pDest->off=pSrc->off;

}

// 북마크는 같은 타입의 뷰끼리만 복사한다. SplitType이 3인 경우는 뷰의 타입이 변경될 때이다.

if (SplitType != 3) {

memcpy(pDest->arMark,pSrc->arMark,sizeof(int)*MAXBOOKMARK);

}

// 수직 스크롤 위치 복사

if (SplitType==AESPLIT_VERT) {

pDest->yPos=pSrc->yPos;

} else if (SplitType==AESPLIT_HORZ) {

if (pDest->nWrap==0 || pSrc->ViewType!=TEXT_VIEW) {

pDest->yPos=pSrc->yPos;

} else {

ViewFirstLine=pSrc->yPos/pSrc->LineHeight;

ViewFirstOff=pSrc->pLine[ViewFirstLine].Start;

pSrc->GetParaFromOff(ViewFirstOff,pr,pc);

ViewFirstLine=pDest->GetParaFirstLine(pr);

pDest->yPos=ViewFirstLine*pDest->LineHeight;

}

}

}

어떤 멤버를 복제하고 어떤 멤버는 복제하지 말아야 하는가는 상식적인 수준에서 쉽게 선택할 수 있다. 일단 절대로 복제해서는 안되는 멤버가 있는데 hWnd 윈도우 핸들은 뷰마다 고유해야 하므로 복제 대상이 아니다. 또한 pLine 정렬 정보도 뷰의 실제 폭에 따라 달라지므로 복제해서는 안되며 뷰를 만든 후에 다시 정렬하여 새로 만들어야 한다. 글꼴에 대한 정보는 복제의 대상이지만 글꼴의 특성값인 FontHeight, FontWidth 등은 복제할 필요가 없는 값이다. 또한 LineRatio로부터 구해지는 LineHeight, TabWidth로부터 구해지는 TabSize 등도 복제할 필요가 없으며 글꼴의 폭에 대한 정보를 가지는 arChWidth, arHanWidth도 SetFont에서 계산되므로 복제할 필요가 없다.

선택 영역을 가리키는 SelStart와 SelEnd는 복제를 할 수도 있고 하지 않을 수도 있는데 이 값을 그대로 복제하면 새로 생성된 뷰도 기존 뷰와 동일한 선택 영역을 가질 것이다. ApiEdit는 정책상 선택 영역은 복제하지 않기로 결정했으므로 이 두 변수는 복제 대상에서 제외된다. 그외 나머지 줄간, 탭폭, 자동 개행 방식, 자동 개행 열, 글꼴 등은 모두 복제하되 Set 함수를 일일이 호출할 필요는 없고 변수에 직접 대입한 후 SetFont만 호출하면 된다. SetFont 함수는 대입된 값을 근거로 파생값을 계산해 내며 전체 정렬하여 pLine까지 생성한다.

출력에 영향을 미치는 값들은 단순히 복사하기만 하면 된다. 마진 폭이나 각종 보기 옵션값들은 OnPaint가 호출되기 전에는 사용되지 않으므로 CloneView에서 복사만 해 놓으면 뷰가 화면에 보이기 전에 적용된다. 이 값들은 정렬 상태에 전혀 영향을 미치지 않기 때문에 SetFont 후에 대입만 하면 된다.

복사 방법이 좀 특수한 것도 있는데 분석기는 객체이기 때문에 그 포인터를 복사하는 것은 의미가 없고 기존 뷰의 분석기 ID를 조사한 후 새 뷰에도 동일한 ID의 분석기를 지정해야 한다. 그래야 새로 생성되는 뷰도 자신만의 고유한 분석기 객체를 가질 수 있다. 또한 분석기는 생성될 때마다 각 구문에 적용되는 색상을 옵션으로부터 복사받아야 하므로 SetStyleColor 함수를 호출해야 한다. 그래서 옵션에서 변경한 구문 분석 색상이 분할된 창에도 적용된다.

현재 편집 위치를 가리키는 off는 대개의 경우 단순 복사가 가능하다. 그러나 아주 특수한 경우는 약간의 조작이 필요한데 헥사 뷰에서 한글의 경계를 가리키고 있을 때는 한글의 시작 위치를 가리키도록 off를 조정해야 한다. 규칙상 off가 DBCS의 경계에 올 수 없으며 이를 방치하면 오프셋을 관리하는 함수들이 정신을 못차린다. DBCS의 경계에 있는지는 IsInDBCS 함수가 판별하며 경계에 있을 경우 바로 앞 문자를 찾음으로써 DBCS 선두에 off를 맞춘다.

IsInDBCS 함수는 앞쪽 32바이트로 이동한 후 여기서부터 세어 오되 단 음수 오프셋으로는 이동하지 않는다. 어디까지나 확률적인 계산에 의지하는 방식인데 정확한 방법은 아니지만 틀린다고 해도 크게 문제되지는 않으므로 일단 간단한 방법을 쓰기로 하자. 32바이트 앞쪽에서부터 계산해 오면 틀릴 확률이 거의 없지만 차후에 좀 더 개선할 여지가 있다. FindParaStart 함수로 문단 선두를 찾을 수도 있지만 이진 포맷에는 개행 코드가 없으므로 너무 느리다는 단점이 있어 쓸 수가 없다.

북마크는 같은 타입의 뷰끼리만 복제할 수 있다. 즉 텍스트 뷰에서 텍스트 뷰를 복제할 때나 헥사 뷰에서 헥사 뷰를 복제할 때만 북마크가 호환된다. 텍스트 뷰는 문단에 대해 북마크를 하지만 헥사 뷰는 줄에 대해 북마크를 하기 때문에 상호 북마크 포맷이 호환되지 않는다. 수평으로나 수직으로나 창이 분할되어 복제할 때는 두 뷰의 타입이 같으므로 북마크를 복사한다. 하지만 뷰의 타입이 변경되는 특수한 경우(SplitType이 3)는 복사하지 않는다.

뷰의 속성 중 가장 특별하게 관리되는 대상은 수직 스크롤 위치를 가리키는 yPos인데 이 값을 복사할 것인가 아닌가는 분할 방향에 따라 달라진다. 일단 수직 분할이면 yPos는 별 제한없이 복사할 수 있다. 기존 뷰가 10번째 줄을 보여주고 있다면 분할된 뷰도 10번째 줄을 보여 주면 된다. 수평 분할일 때도 자동 개행 상태가 아니거나 헥사 뷰처럼 자동 개행이 의미가 없는 뷰이면 마찬가지로 yPos를 복사할 수 있다.

가장 골치아픈 경우는 자동 개행 상태의 뷰를 수평으로 분할할 때인데 이때는 yPos를 복사하는 것이 아무 의미가 없다. 왜냐하면 자동 개행 상태에서는 뷰의 폭에 따라 정렬 상태가 달라지므로 yPos를 복사한다고 해서 기존 뷰와 동일한 곳을 가리킬 수 없기 때문이다. 그래서 기존 뷰의 첫번째 문단 번호를 조사해 두고 분할된 뷰도 이 문단을 가리키도록 해야 한다. 단, 헥사 뷰에서는 문단의 개념도 없고 자동 개행이라는 상태도 없으므로 이 서비스는 텍스트 뷰일 때만 가능하다.

수평, 수직 둘 다 아닐 때는 yPos를 전혀 건드리지 않으므로 새로운 뷰의 yPos는 0으로 초기화될 것이다. CloneView는 SplitView에서뿐만 아니라 뷰 타입을 전환할 때도 호출되는데 이때는 SplitType이 0이 된다.

사. 뷰의 배치

SplitView 함수는 새로 뷰를 생성한 후 분할 비율에 따라 HorzRatio, VertRatio 변수만 조정하고 새로 만들어진 뷰를 배치하는 작업은 OnSize에서 한다. 프레임의 OnSize함수를 다음과 같이 완전히 다시 작성한다.

void CApiEdit::OnSize(HWND hWnd, UINT state, int cx, int cy)

{

RECT crt;

int width,height;

if (state == SIZE_MINIMIZED) {

return;

}

GetClientRect(hWnd,&crt);

// 분할되지 않은 경우

if (arView[1]==NULL) {

MoveWindow(arView[0]->hWnd,0,0,crt.right,crt.bottom,TRUE);

// 2분할된 경우

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

if (VertRatio) {

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

MoveWindow(arView[0]->hWnd,0,0,crt.right,height,TRUE);

MoveWindow(arView[1]->hWnd,0,height+VGAP,crt.right,crt.bottom-height-VGAP,TRUE);

} else {

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

MoveWindow(arView[0]->hWnd,0,0,width,crt.bottom,TRUE);

MoveWindow(arView[1]->hWnd,width+VGAP,0,crt.right-width-VGAP,crt.bottom,TRUE);

}

// 4분할된 경우

} else {

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

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

MoveWindow(arView[0]->hWnd,0,0,width,height,TRUE);

MoveWindow(arView[1]->hWnd,width+VGAP,0,crt.right-width-VGAP,height,TRUE);

MoveWindow(arView[2]->hWnd,0,height+VGAP,width,crt.bottom-height-VGAP,TRUE);

MoveWindow(arView[3]->hWnd,width+VGAP,height+VGAP,crt.right-width-VGAP,

crt.bottom-height-VGAP,TRUE);

}

}

분할 개수에 따라 뷰를 적절히 배치하는데 뷰의 개수는 arView 배열값을 점검해 보면 쉽게 알 수 있다. arView[1]이 NULL이면 arView[0]에 하나의 뷰만 있다는 뜻이므로 이때는 프레임의 작업 영역 전체를 뷰로 가득 채우면 된다. arView[1]이 NULL이 아니라면 최소한 둘 이상으로 분할되어 있다는 뜻인데 이때 arView[2]를 보면 2분할 상태인지 4분할 상태인지 알 수 있다. 4분할 상태이면 4개의 뷰를 HorzRatio, VertRatio 비율에 따라 배치한다. 2분할 상태이면 분할 방향에 따라 2개의 뷰를 좌우로 또는 상하로 배치한다.

분할 비율과 현재 분할 상태에 따라 뷰를 적당한 위치에 배치하기만 하면 된다. 프레임이 복수 개의 뷰로 분할되면 프레임의 작업 영역 틈 사이로 VGAP 만큼의 빈 여백이 드러나는데 OnPaint에서 이 여백을 직접 그린다. 프레임은 대부분의 경우 뷰에 의해 가려져 있고 분할되어 있을 때만 작업영역의 일부가 보이는데 프레임의 OnPaint는 이때 뷰 사이로 보이는 여백을 그리기 위해 존재한다.

void CApiEdit::OnPaint(HWND hWnd)

{

HDC hdc;

PAINTSTRUCT ps;

HPEN hHilight,hShadow,OldPen;

HBRUSH hFace;

RECT crt,rt;

int width,height;

hdc=BeginPaint(hWnd,&ps);

if (VertRatio || HorzRatio) {

hHilight=CreatePen(PS_SOLID,1,GetSysColor(COLOR_3DHILIGHT));

hShadow=CreatePen(PS_SOLID,1,GetSysColor(COLOR_3DSHADOW));

hFace=CreateSolidBrush(GetSysColor(COLOR_3DFACE));

GetClientRect(hWnd,&crt);

// 수직 스플릿 바를 그린다.

if (VertRatio) {

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

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

FillRect(hdc,&rt,hFace);

OldPen=(HPEN)SelectObject(hdc,hHilight);

MoveToEx(hdc,rt.left,rt.top+1,NULL);

LineTo(hdc,rt.right,rt.top+1);

SelectObject(hdc,hShadow);

MoveToEx(hdc,rt.left,rt.bottom-1,NULL);

LineTo(hdc,rt.right,rt.bottom-1);

}

// 수평 스플릿 바를 그린다.

if (HorzRatio) {

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

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

FillRect(hdc,&rt,hFace);

OldPen=(HPEN)SelectObject(hdc,hHilight);

MoveToEx(hdc,rt.left+1,rt.top,NULL);

LineTo(hdc,rt.left+1,rt.bottom);

SelectObject(hdc,hShadow);

MoveToEx(hdc,rt.right-1,rt.top,NULL);

LineTo(hdc,rt.right-1,rt.bottom);

}

if (VertRatio && HorzRatio) {

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

FillRect(hdc,&rt,hFace);

}

SelectObject(hdc,OldPen);

DeleteObject(hHilight);

DeleteObject(hShadow);

DeleteObject(hFace);

}

EndPaint(hWnd,&ps);

}

입체적인 모양을 그리다 보니 GDI 오브젝트가 많이 필요하고 그래서 코드가 좀 길어졌는데 단순한 출력문일 뿐이다. OnPaint에서 직접 스플릿 바를 그리는 대신 뷰에 WS_EX_CLIENTEDGE 확장 스타일을 주어도 비슷한 모양을 얻을 수 있다. 이 경우 스플릿 바는 회색으로 채색해야 하는데 그러기 위해서는 프레임이 배경 브러시를 가져야 하고 그러자면 깜박임 현상이 나타나게 된다. 그래서 OnPaint에서 스플릿 바를 직접 그렸다.

뷰의 틈 사이로 조금씩 드러나 보이는 이 여백은 단순한 장식이 아니라 뷰의 분할 비율을 조정하는 일종의 유저 인터페이스이다. 스플릿 박스로 일단 분할한 후 비율을 조정할 때는 프레임의 스플릿 바를 드래그해야 한다. 여기까지 작업한 후 실행해 보면 스플릿 박스를 드래그하여 분할할 수 있다.

그러나 아직 분할만 할 수 있을 뿐이지 스플릿 바를 드래그하여 분할 비율을 조정하거나 분할을 취소하지는 못한다. 이런 분할 관리는 바로 다음 절에서 계속 한다.