app 클래스의 FILE_OPEN 파일열기중 메세지맵 수정해야하는 사항

과거 클래스 위자드에서 어떤 이벤트 메시지를 추가하면 적당한 위치에 알맞게 잘 들어갔던 반면, 지금은 추가를 하게 되면 코드의 가독성도 꽝이고, 무엇보다 전혀 의도하지 않은 위치에 들어가버린다. 그 중 메시지 맵에서 이벤트 메시지를 추가할 때 매우 조심스럽게 해야할 부분이 있어 글을 남긴다.


사용자가 이벤트 핸들러 함수를 추가 했을 경우, 또는 재정의 했을 경우 반드시 아래의 굵게 표시한 곳으로 옮기던지, 이전의 동일한 아이디의 핸들러 함수를 주석처리하여야 사용자의 함수가 정상적으로 호출된다.


BEGIN_MESSAGE_MAP(CMyToolApp, CWinApp)
    ON_COMMAND(ID_APP_ABOUT, &CMyToolApp::OnAppAbout)
    ON_COMMAND(ID_FILE_OPEN, &CMyToolApp::OnFileOpen)
    // 표준 파일을 기초로 하는 문서 명령입니다.
    ON_COMMAND(ID_FILE_NEW, &CWinApp::OnFileNew)
    //ON_COMMAND(ID_FILE_OPEN, &CWinApp::OnFileOpen)
    ON_COMMAND(ID_FILE_OPEN, &CMyToolApp::OnFileOpen)
END_MESSAGE_MAP()

---

CWinApp 를 상속받은 사용자 App 클래스가 있다고 하자. 그 클래스를 CMyToolApp 라고 하자. 그리고 프로그램에서 파일을 열고 새 파일을 만드는 아이디를 각각 ID_FILE_OPEN 과 ID_FILE_NEW 처럼 기본으로 정의되어 있는 아이디를 사용한다고 하자.

이때 ID_FILE_OPEN 을 재정의하여 몇가지 기능을 추가한다고 한다면 클래스 뷰에서 CMyToolApp 에서 속성창을 열고, 속성창에서 이벤트 아이콘을 누른 후 이벤트 핸들러 함수로 만들 아이디 ID_FILE_OPEN 에서 COMMAND 이벤트 헨들러 함수를 추가하면 자동으로 코드가 추가가된다.

그 중 아래의 메시지 맵에서 매우 조심해야하는 부분이 있다.


BEGIN_MESSAGE_MAP(CMyToolApp, CWinApp)
    ON_COMMAND(ID_APP_ABOUT, &CMyToolApp::OnAppAbout)
    // 표준 파일을 기초로 하는 문서 명령입니다.
    ON_COMMAND(ID_FILE_NEW, &CWinApp::OnFileNew)
    ON_COMMAND(ID_FILE_OPEN, &CWinApp::OnFileOpen)
    ON_COMMAND(ID_FILE_OPEN, &CMyToolApp::OnFileOpen)
END_MESSAGE_MAP()


자동으로 추가가 되는 위치가 위에서 굵게 표시한 곳이다.
하지만 저곳에 추가가 되면 다음과 같은 문제가 생긴다.

우리가 새롭게 재정의한, 추가한, OnFileOpen() 함수가 호출되지 않고 CWinApp 의 OnFileOpen() 함수가 호출이 되어버린다.

즉, 동일한 아이디는 가장 먼저 만나는, 소스 코드 상에서 위쪽에 있는 것만을 실행시키고 메시지 맵을 벗어나버린다. 마치 switch() 문에서 동일한 케이스가 있다면 위쪽의 case만 되는 것과 같다.

과거 VC++ 6.0 일 때는 위와 같은 상황에서 메시지 맵이 추가가 되는 부분이 정해져있었다.


BEGIN_MESSAGE_MAP(CMyToolApp, CWinApp)
    //{{AFX_MSG_MAP(CMyToolApp)
    ON_COMMAND(ID_APP_ABOUT, OnAppAbout)
    ON_COMMAND(ID_FILE_OPEN, OnFileOpen)
    //}}AFX_MSG_MAP
    // Standard file based document commands
    ON_COMMAND(ID_FILE_NEW, CWinApp::OnFileNew)
    ON_COMMAND(ID_FILE_OPEN, CWinApp::OnFileOpen)
END_MESSAGE_MAP()


위에서 굵게 되어 있는 블럭 안에 사용자 이벤트 핸들러 함수를 자동으로 추가를 시켜줬었다. 항상 상위 클래스의 것보다 자신의 클래스의 핸들러 함수가 위쪽에 추가되었기 때문에 문제가 없었다.