감사합니다.

마이크로 소프트사의 윈도우는 윈도우프로시져(WindowProc)라고 불리는 메세지 처리함수를 기반으로 동작한다.

기본 함수는 DefWindowProc이다.

메세지 드리븐 방식(message driven architecture)이라고 한다.

PC에서 발생하는 대부분의 이벤트는 메세지형식으로 가공되어, 각 프로그램(창,윈도우)의 WindowProc함수로 보내진다.

예를 들면, 키보드의 키를 누르면, WindowProc함수로 WM_KEY관련 메세지가 전달된다.

WindowProc의 장점

- 1개의 함수로 다양한 기능을 구현.

- 확장성이 좋다

단점

- 매번 메세지를 비교해야하므로 느리다.

WindowProc와 반대 개념의 방식

각 이벤트마다 전용의 처리함수가 존재하여, 해당 이벤트를 전용 함수에서 처리하는 방식.

예) OnKey(...)

프로그램의 편의를 위해, 각 이벤트 함수들은 함수포인터로 존재하며,

이는 클래스에서는 가상함수(버추얼함수)로 볼 수 있다.

WindowProc방식은 메세지를 재귀적으로 처리가 가능하다.

예) WM_xxx메세지가 입력된 경우,

WindowProc함수에서,  WindowProc함수로 WM_yyy메세지를 보내어 추가적인 처리를 할 수 있다.

MyWindowProc(msg)

{

    switch(msg)

    {

    case WM_xxx:

        if(...)

        {

           SendMessage(WM_yyy);//MyWindowProc()함수로 다시 들어옴. 재귀호출.

        }

        break;

    ...

    }

}

SendMessage는 메세지를 WindowProc로 보내고, 처리가 끝날때까지 기다린다.

PostMessage는 메세지 처리 대기열(FIFO)에 메세지만 넣고, 다음 명령을 실행한다.

어쨌거나, 메세지 처리방식인 경우, 메세지를 처리하다가, 새로운 메세지를 생성해야하는 경우,

메세지 처리함수의 처음부터 다시 처리가 되어야 한다는 문제가 있다.

장점으로는 최소한의 수정으로 동작이 가능해지므로, 확장성이 좋다.

단점으로는 느리다.

확장성이 중요하지 않고, 처리속도가 중요한 경우에는 SendMessage함수를 사용하지 말고,

직접 처리함수를 호출하는것이 좋다.

그러나, 직접 처리함수를 호출할 경우, 확장성이 떨어지는 문제가 있다.

예) A루틴에서는 메세지처리방식으로 작성이 되어 있으나,

"추가기능1"을 넣기위해, 메세지 처리방식으로 작성할 경우,

메세지처리함수를 2번씩 통과해야 하므로, 전체적인 처리속도가 느려진다.

메세지를 1번만 비교하고(메인 메세지 처리함수에서 즉시 처리), 전용 처리함수를 호출할 경우,

기존 소스코드도 수정해야한다.(속도는 빨라지지만, 확장성은 떨어진다)

마이크로 소프트 윈도우는 메세지 처리방식으로 되어 있어, 확장성은 좋으나,

특정 메세지에 대해서는 수십번의 메세지 재처리과정이 필요하여, 속도가 느려진다.

예) 메세지1 -> 메세지2발생 -> 메세지2처리 -> 다시 메세지1 처리