. 클립보드 처리

SetText 외에 외부의 데이터를 읽는 또 다른 루틴은 클립보드에서 붙여넣기를 할 때이다. 클립보드에 데이터를 넣은 프로그램이 유니코드 포맷으로 문자열을 넣을 수도 있기 때문에 붙여넣기 전에 내부 포맷과 호환되는지 점검해보고 호환되지 않는다면 먼저 변환한 후 붙여넣어야 한다. OnCommand IDM_AE_PASTE의 코드를 다음과 같이 수정한다.

 

void CApiEdit::OnCommand(HWND hWnd, int id, HWND hwndCtl, UINT codeNotify)

{

     ....

     case IDM_AE_PASTE:

          BOOL bPrevSel;

        TCHAR *dest;

        int Format;

          if (IsClipboardFormatAvailable(CF_TEXT) && bReadOnly==FALSE && bCapture==FALSE) {

              if (SelStart != SelEnd) {

                   StartUndoGroup();

              }

              bPrevSel=DeleteSelection();

              DeleteSelection();

              OpenClipboard(hWnd);

              hmem=GetClipboardData(CF_TEXT);

              ptr=(TCHAR *)GlobalLock(hmem);

           Format=AnalyzeFormat(ptr, -1);

           if (Format != AE_FORMAT_WIN) {

               ConvertFormat(Format,AE_FORMAT_WIN,ptr,dest);

               Insert(off,dest);

               free(dest);

           } else {

                   Insert(off,ptr);

           }

              if (bPrevSel) {

                   EndUndoGroup();

              }

              GlobalUnlock(hmem);

              CloseClipboard();

              Invalidate(FindParaStart(off));

              off += lstrlen(ptr);

              SetCaret();

          }

          return;

 

클립보드에 있는 데이터가 텍스트 포맷임을 먼저 확인했으므로 이진 포맷인지 점검해 볼 필요는 없다. 클립보드의 데이터가 윈도우즈 포맷이 아니면 변환 후 삽입하였으며 다른 프로그램이 어떤 포맷의 텍스트라도 클립보드에 넣어 놓으면 편집 포맷으로 바꿔서 가져온다.

이상으로 포맷변환 루틴을 모두 작성했다. ApiEdit의 포맷 지원 정책의 핵심은 편집시에는 한 포맷만 인식하되 외부 입출력시에 다른 포맷으로 변환을 하도록 하는 것이다. 덕분에 편집코드가 단순해지고 편집속도도 빠르며 유지 보수가 쉽다. 차후에 지원 포맷을 늘려야 할 때 확장하기에 유리하다는 이점도 있다. 하지만 정책이 단순하기 때문에 단점도 많을 수밖에 없다.

가장 큰 단점은 내부 포맷과 다른 파일을 읽는 속도가 느려진다는 점이다. 변환을 해야 정렬을 할 수 있고 정렬을 해야 화면에 출력할 수 있으니 파일의 내용을 확인하는데 시간이 걸릴 수밖에 없다. 이 단점은 특히 텍스트 뷰어로 큰 파일을 확인할 때 두드러지게 나타난다. 편집 루틴의 부담이 파일 입출력 루틴으로 전가되었다고 할 수 있다. 또 다른 단점은 인코딩 방식에 따라 표현하지 못하는 문자가 있을 수 있다는 점이다. ANSI 포맷에 있는 모든 글자가 유니코드에도 있다고 보장할 수 없으며 반대도 마찬가지다.

ApiEdit가 이런 정책을 채용하게 된 이유는 솔직히 말해서 처음부터 포맷변환을 고려하지 못했기 때문이다. 만약 최초 기획시에 이 기능을 고려했다면 모든 편집코드에서 포맷에 따라 다른 처리를 하도록 했을 것이며 지금의 모양과는 많이 달라졌을 것이다. ApiEdit가 지금 채택하고 있는 정책이 분명 최상의 정책이 아니라는 것은 분명한 것 같고 다음 버전에서는 이 정책에 대해 다시 한 번 검토를 해 볼 생각이다.