1.상용구

가.상용구 레코드

상용구란 쉽게 말해서 자주 입력하는 문장이다. 예를 들어 고객에게 보낼 안내장을 작성하고 있다면 "감사합니다"라는 문장을 자주 입력할 것이고 만화 영화에 대한 논문을 작성한다면 "로보트 태권 V"나 "아기공룡 둘리"따위를 자주 언급할 것이다. 수시로 입력할 문장을 상용구로 등록해 놓으면 일일이 타이프를 치지 않아도 빠르게 입력할 수 있어 편리하다. 워낙 보편적인 기능이라 텍스트 편집기는 물론 워드 프로세서들도 상용구를 지원한다.

개발자에게도 상용구 기능은 아주 실용적인데 C 코딩을 하다보면 for (i=0;i<n;i++) { 같은 반복문이나 switch case 같은 선택문은 늘상 입력해야 한다. 이런 문장을 상용구로 등록해 놓으면 코드 작성 시간이 빨라질 뿐만 아니라 오타도 줄일 수 있다. 상용구는 단순히 문장을 대신 입력해 주는 정도의 기능만 가지는 것이 아니라 자주 사용하는 문서의 틀을 자동으로 생성하는 기능을 가지기도 한다. 특히 HTML이나 자바 스크립트처럼 늘상 비슷 비슷한 코드를 베껴 쓰는 개발자들에게 상용구 기능이 특히 유용하다.

상용구는 매크로나 단축키와는 달리 별도의 분리된 파일에 저장한다. 레지스트리에 저장하기에는 너무 클 뿐만 아니라 정성들여 작성한 상용구는 재사용 가능해서 사용자들끼리 파일을 서로 교환할 수도 있다. 이런 재사용성을 높이기 위해 하나의 상용구 파일에 여러 개의 텍스트를 계층적으로 저장하여 수가 많아도 쉽게 검색할 수 있게 할 것이다.

상용구는 호스트의 기능이며 대부분의 관리 코드가 호스트에 작성되지만 컨트롤도 상용구를 위한 약간의 지원을 해야 한다. 상용구 삽입 후 미리 지정한 곳으로 캐럿을 이동한다거나 사용자가 입력할 부분을 미리 선택해 놓는 기능은 컨트롤이 지원해야 한다. 또한 자동 상용구같은 고급 기능은 컨트롤과 호스트가 상호 협조적으로 동작해야 원할하게 지원할 수 있다. 다음 구조체는 상용구 하나를 저장한다. 실습 초반에 미리 만들어 두었던 Clip.h에 이 구조체를 선언한다.

// 상용구 구조체

class CClipRecord

{

public:

CClipRecord();

int Parent;

int Type;

TCHAR Name[32];

TCHAR AutoName[16];

TCHAR *Content;

int len;

int DefAction;

TCHAR FontFace[32];

BYTE PitchAndFamily;

BYTE CharSet;

BYTE FontSize;

COLORREF cFore,cBack;

int nWrap;

int nParser;

int nView;

int LineRatio;

BYTE Reserved[16];

};

enum {DGCT_FOLDER=1, DGCT_CLIP };

형태상으로 생성자를 가지는 클래스이지만 실제로는 단순한 구조체이다. 생성자는 Clip.cpp에 다음과 같이 작성한다.

CClipRecord::CClipRecord()

{

memset(this,0,sizeof(CClipRecord));

}

객체의 모든 멤버를 0으로 채워 빈 상태로 레코드를 초기화한다. 레코드의 구조는 프로젝트와 유사한데 둘 다 계층적인 자료를 저장한다는 면에서 공통점이 있다. Parent 멤버가 부모 레코드의 첨자를 가리키며 -1일 경우 루트 바로 아래에 있다는 뜻이다. Type은 레코드의 종류를 지정하는데 1이면 폴더이고 2이면 상용구다. Parent와 Type 멤버에 의해 상용구 레코드끼리 계층을 구성한다.

Name은 상용구의 이름이며 최대 31자까지 가능하다. 상용구의 내용을 잘 표현할 수 있는 설명적인 이름을 붙이는 것이 좋다. AutoName은 자동 삽입명이며 본문에서 자동 삽입명을 입력하면 바로 상용구를 삽입하는 기능이 있다. 예를 들어 "안녕하세요"라는 상용구의 자동 삽입명을 "인사"라고 작성해 놓고 "인사"라고만 치면 "안녕하세요"를 삽입한다. 자동 상용구 기능은 별도의 단축키가 아니라 문자키로 상용구를 바로 삽입할 수 있으므로 편리하다. 두 이름의 길이는 적당한 수준에서 결정했는데 상용구는 항상 열려 있기 때문에 너무 길면 메모리 낭비가 심해진다.

Content는 상용구의 실제 내용이며 이 문자열이 문서에 삽입된다. 가변 길이를 가지므로 실행중에 필요한만큼 할당 및 재할당되며 레코드는 그 포인터만 기억한다. len은 내용의 길이이다. DefAction은 상용구 창에서 상용구를 더블클릭했을 때 어떤 동작을 할 것인가를 지정하며 삽입, 복사, 새 파일로 셋 중 하나를 선택할 수 있다.

나머지 멤버는 상용구 문자열을 보여 주기 위한 속성들인데 당근은 이 중 구문 분석기를 정의하는 nParser만 사용한다. 나머지 멤버는 상용구와는 잘 어울리지 않지만 확장을 위해 미리 포함해 두었다. 상용구 하나를 일반적인 문서처럼 취급할 경우 상용구 묶음은 텍스트 파일의 집합이 될 수 있는데 이때 각 문서가 개별적으로 다른 속성을 가질 수도 있을 것이다. 당근 상용구 파일은 파일 묶음 포맷을 정의하며 여러 모로 활용할 여지가 많아 확장성을 고려하였다.

마지막 멤버인 Reserved는 여우분인데 앞으로 더 필요한 필드를 위해 16바이트의 공간을 미리 확보해 두었다. 장래에 미리 어떤 필드가 더 필요할지 예측하기 힘들므로 최대한 하위 버전 호환성을 유지하기 위해 예비 용량을 남겨 두는 것이다. 상용구는 영구적인 파일로 저장되기 때문에 당근이 업그레이드되더라도 이전 버전과 포맷이 호환되어야 한다.

나.상용구 묶음

상용구 묶음은 상용구 레코드의 집합이며 파일로 저장되는 포맷이기도 하다. 전체적인 구조는 프로젝트 파일과 거의 유사하다. 헤더와 본체로 구성된다.

// 상용구의 헤더

struct SClipHeader

{

TCHAR Text[64];

int Ver;

TCHAR Name[64];

TCHAR Desc[128];

int Num;

BYTE Reserved[16];

};

// 상용구 파일

class CClipFile

{

public:

SClipHeader Header;

CClipRecord *arRecord;

CClipFile();

~CClipFile();

int Load(TCHAR *Path);

BOOL Save(TCHAR *Path);

};

헤더는 안내문, 상용구 묶음의 이름과 버전 정보, 총 상용구 레코드의 개수 등에 대한 기본적인 정보를 가진다. 확장을 위해 여기에도 약간의 여유분을 주었다. CClipFile 클래스는 헤더와 레코드 배열을 멤버로 가지며 상용구 묶음을 관리하는 멤버 함수를 정의한다. 멤버 함수는 Clip.cpp에 작성한다.

// 완전히 텅 빈 상태로 생성

CClipFile::CClipFile()

{

memset(&Header,0,sizeof(SClipHeader));

lstrcpy(Header.Text,"당근 상용구 파일입니다.Dangeun Clip File");

Header.Ver=120;

arRecord=NULL;

}

CClipFile::~CClipFile()

{

int i;

// 상용구의 내용도 해제한다.

if (arRecord) {

for (i=0;i<Header.Num;i++) {

if (arRecord[i].Content) {

free(arRecord[i].Content);

}

}

free(arRecord);

}

}

// 파일에서 읽어서 메모리로 올림

int CClipFile::Load(TCHAR *Path)

{

HANDLE hFile;

DWORD dwRead;

BOOL Result=0;

int i;

hFile=CreateFile(Path,GENERIC_READ,0,NULL,

OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);

if (hFile==INVALID_HANDLE_VALUE) {

return -1;

}

// 헤더 먼저 읽음

ReadFile(hFile,&Header,sizeof(SClipHeader),&dwRead,NULL);

if (Header.Ver != 120) {

Result=-2;

goto end;

}

// 레코드가 없으면 더 읽을 거 없음

if (Header.Num == 0) {

goto end;

}

// 레코드수만큼 메모리 할당하고 레코드를 통째로 읽어들임

arRecord=(CClipRecord *)malloc(Header.Num*sizeof(CClipRecord));

ReadFile(hFile,arRecord,Header.Num*sizeof(CClipRecord),&dwRead,NULL);

// 내용 읽음

for (i=0;i<Header.Num;i++) {

if (arRecord[i].Type == DGCT_CLIP) {

arRecord[i].Content=(TCHAR *)calloc(arRecord[i].len+1,1);

ReadFile(hFile,arRecord[i].Content,arRecord[i].len,&dwRead,NULL);

}

}

end:

CloseHandle(hFile);

return Result;

}

// 파일로 저장.

BOOL CClipFile::Save(TCHAR *Path)

{

HANDLE hFile;

DWORD dwWritten;

int i;

int ConOff;

CClipRecord cr;

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

CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);

if (hFile==INVALID_HANDLE_VALUE) {

return FALSE;

}

// 헤더 먼저 출력

WriteFile(hFile,&Header,sizeof(SClipHeader),&dwWritten,NULL);

// 레코드 출력. 포인터는 오프셋으로 바꾸어 저장한다. 단, 폴더는 제외

ConOff=sizeof(SClipHeader)+Header.Num*sizeof(CClipRecord);

for (i=0;i<Header.Num;i++) {

cr=arRecord[i];

if (cr.Type == DGCT_CLIP) {

// 이 오프셋은 임의 접근을 위해 필요함. 순서대로 읽을 때는 사실 필요가 없음

cr.Content=(TCHAR *)ConOff;

ConOff+=cr.len;

}

WriteFile(hFile,&cr,sizeof(CClipRecord),&dwWritten,NULL);

}

// 상용구 문자열 출력

for (i=0;i<Header.Num;i++) {

if (arRecord[i].Type == DGCT_CLIP) {

WriteFile(hFile,arRecord[i].Content,arRecord[i].len,&dwWritten,NULL);

}

}

CloseHandle(hFile);

return TRUE;

}

생성자는 레코드가 하나도 없는 상태로 묶음을 초기화한다. 헤더에 안내문과 버전 정보만 작성해 두었다. 파괴자는 레코드 배열에 할당된 모든 메모리와 레코드 배열 자체를 해제한다. Load와 Save는 묶음 전체를 파일로 저장하거나 복구한다. 상용구 묶음은 파일에 저장될 때와 메모리로 올라왔을 때의 모양이 다르다. 파일에 저장될 때의 모양은 다음과 같다.

헤더 다음에 바로 arRecord 배열이 이어지며 레코드 개수는 Header의 Num 멤버가 기억한다. 각 레코드의 Content 멤버는 상용구의 실제 내용이 파일의 어디쯤에 있는지 오프셋을 기억한다. 파일은 바이트의 스트림이므로 실제 내용 위치를 오프셋으로 기억해야 하며 포인터는 아무 의미가 없다. len은 내용의 길이이며 정확한 길이를 유지하므로 파일에 저장되는 상용구 내용은 NULL 종료되지 않아도 상관없다. 레코드 배열 다음에 상용구의 실제 내용인 텍스트들이 이어진다. 가변 길이이기 때문에 레코드 배열에 같이 포함할 수 없으며 레코드 배열 다음에 이어진다.

Load 함수는 레코드 배열을 읽어들인다. 먼저 헤더를 읽어 버전 번호가 유효한지, 상용구가 존재하는 파일인지를 점검한다. 그리고 헤더의 Num수만큼 배열을 할당하며 이 수만큼 레코드를 읽어들인다. 순서대로 각 레코드의 길이만큼 Content 멤버를 할당하고 내용을 읽어들이기만 하면 된다. 이때는 순차 접근을 하므로 Content에 저장된 오프셋을 참조할 필요가 없다. Content의 오프셋은 임의 접근을 할 때만 필요하다. 묶음이 메모리에 읽혀졌을 때의 모양은 다음과 같다.

arRecord 배열은 헤더의 Num 개수만큼 동적으로 할당된다. 각 레코드의 Content는 상용구의 실제 내용을 가지는 메모리의 포인터인데 여기가 어디쯤 될 지는 예측할 수 없다. malloc으로 레코드의 len+1만큼 할당되어 메모리의 어딘가에 존재할 것이며 그 포인터를 Content가 가리키고 있다. 널 종료 문자열로 관리되므로 메모리에 올라와 있을 때 len 멤버는 전혀 사용되지 않는다.

파일로 존재할 때와 메모리에 전개되었을 때의 모습이 이렇게 다른 근본적인 이유는 메모리에 올라왔을 때는 Content 내용이 언제든지 편집될 수 있기 때문이다. 길이가 늘었다 줄었다 할 수 있기 위해서 Content를 수시로 재할당해야 하므로 그 타입이 TCHAR *여야 한다. 하지만 파일은 연속적인 바이트 스트림으로 저장해야 하므로 Content는 오프셋이어야 한다.

Save 함수는 메모리에 편집중인 레코드 배열을 파일로 저장한다. 헤더 먼저 출력하고 각 레코드 배열의 Content를 오프셋으로 조사하여 출력한다. 상용구 내용까지 완전히 파일로 출력되기 전까지 Content가 가리키는 포인터를 유지하기 위해 임시 구조체 cr에 정보를 작성한 후 출력했다.임시 구조체 cr의 Content는 레코드 배열 다음의 누적 오프셋으로 계산된다. 이 오프셋은 순차 접근을 할 때는 사실 필요치 않으나 임의 접근을 위해 필요하다. 레코드 배열을 모두 기록한 후 상용구의 실제 내용인 Content가 가리키는 문자열을 길이만큼 순서대로 출력한다.