. 컨트롤 점검

마지막으로 ApiEdit가 지금까지 컨트롤로서 독립성을 잘 유지하고 있는지 점검해보도록 하자. 컨트롤화를 하면서 테스트 예제로 만들었던 NonSool 예제의 ApiEdit를 새로 만든 ApiEdit로 교체하여 새로운 프로젝트 NonSool2를 만들었다. 새로 추가된 Parse.h, Parse.cpp, AeUtil.h, AeUtil.cpp도 프로젝트에 같이 포함시켜야 하며 이 프로젝트는 미리 컴파일된 헤더를 사용하지 않으므로 stdafx.h 인클루드문을 주석 처리해야 한다.

그 외의 나머지 코드는 전혀 손대지 않아도 된다. 다만 대화상자에서 컨트롤의 탭키 양보가 제대로 되는지 테스트해보기 위해 NonSool.cpp에 다음 두 문장을 추가해보자. h1, h2에 대해서만 bWantTab 옵션을 꺼 주었다.

 

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

{

     switch(iMessage)

     {

     case WM_INITDIALOG:

          hDlgMain = hDlg;

          h1.Create(0,0,0,0,WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP,100,hDlg);

          h2.Create(0,0,0,0,WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP,101,hDlg);

          h3.Create(0,0,0,0,WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP,102,hDlg);

        h1.SetWantTab(FALSE);

        h2.SetWantTab(FALSE);

          SetFocus(h1.hWnd);

          return FALSE;

 

실행 결과는 다음과 같다. 서론, 본론 필드에서는 <Tab>키를 눌러 다음 필드로 이동할 수 있지만 결론 필드에서는 <Tab>키가 동작하지 않을 것이다.

보다시피 ApiEdit는 아직까지 독립된 컨트롤이며 다른 프로젝트에 가져가도 잘 동작한다. 추가된 옵션이나 단축키 등에 대해서는 호스트가 지원해야 하며 호스트가 컨트롤의 기능을 활성화하지 않으면 ApiEdit는 디폴트 설정대로 실행된다. 예를 들어 문법 분석을 하도록 하고 싶다면 SetParser를 호출해야 하고 검색을 하고 싶으면 검색 대화상자를 제공해야 한다.