WINDOWS 메시지 처리 프로세스

1. 소개

2. Windows 메시지 메커니즘의 개념

1. DOS와 Windows 드라이버 메커니즘의 차이점

2 . 메시지

3. 메시지 출처

4. Windows 메시지 시스템 구성

5. Windows 메시지 메커니즘의 핵심 사항

1. 창 절차

2 메시지 유형

3 메시지 대기열(Message Queues)

4 대기열 메시지 및 대기열이 아닌 메시지 메시지

5 Windows 메시지 기능

6 메시지 교착 상태

7 BroadcastSystemMessage

MFC 메시지 메커니즘< /p >

1. MFC 프레임워크에서 Windows로부터 메시지를 수신하고 처리하는 과정

2. MFC 내부 메시지 처리 방법

1.

C++에서는 프로그램 아키텍처 기사에서 프로그램이 여러 계층과 모듈로 구성되어 있음을 확인했습니다. 그러면 이러한 모듈 간에, 그리고 프로그램과 Windows 간에 정보를 어떻게 전송합니까? ? Windows 메시지 메커니즘이 이를 담당하며, 이는 Windows의 핵심 부분입니다.

메시지에는 데이터와 지침이 포함됩니다.

2.

1. DOS와 Windows 드라이버 메커니즘의 차이점

1) DOS는 프로세스 중심입니다.

전통적인 MS-DOS 프로그램은 주로 순차적입니다. 프로그래밍에 대한 관계형 프로세스 중심 접근 방식입니다. 프로세스는 특정 시작, 중간, 끝이 있는 미리 정의된 작업 시퀀스의 조합입니다. 프로그램은 프로그램 이벤트 및 절차의 순서를 직접 제어합니다. 이런 종류의 프로그래밍 방법은 사용자 중심이 아닌 프로그램 중심이고, 상호작용성이 좋지 않으며, 사용자가 특정 불변 모드에 ​​따라 작업하도록 강요하기 때문에 사용자 인터페이스가 충분히 친숙하지 않습니다. 기본 모델은 그림 1.1에 나와 있습니다.

2) Windows는 이벤트(메시지) 중심입니다.

이벤트 중심 프로그래밍은 이벤트 순서에 따라 제어되는 것이 아니라 이벤트 순서에 따라 제어되는 새로운 프로그래밍 방법입니다. 이러한 이벤트의 발생은 무작위적이고 불확실하며 미리 정해진 순서가 없습니다. 이를 통해 프로그램 사용자는 다양한 합리적인 순서로 프로그램 흐름을 배열할 수 있습니다. 사용자 상호 작용이 필요한 애플리케이션의 경우 이벤트 중심 프로그래밍에는 프로세스 중심 방법으로 대체할 수 없는 장점이 있습니다. 프로그래밍 과정에서 필요한 기능을 완성하는 것 외에도 사용자로부터 가능한 다양한 입력을 고려하고 그에 따른 처리 절차를 설계하는 사용자 중심 프로그래밍 방법입니다. 프로그램이 실행되기 시작하면 사용자가 이벤트를 입력하기를 기다리는 상태에 있다가, 그 이벤트를 획득하고 이에 따라 응답하고, 처리 후에는 반환되어 대기하는 상태에 있는 것이다. 이벤트를 위해. 해당 블록 다이어그램은 그림 1.2에 나와 있습니다.

2. 메시지

Windows 시스템은 이벤트 중심 OS이므로 모든 이벤트가 발생하면 메시지가 생성됩니다. 메시지를 통해 어떤 사건이 일어났는지, 그 사건을 이해하고, 그 사건을 해결해보세요. 뉴스란 무엇입니까? 정의하기 어렵기 때문에 다양한 측면에서 설명해보자:

1) 메시지 구성: 메시지는 메시지 이름(UINT)과 두 개의 매개변수(WPARAM, LPARAM)로 구성된다. 사용자가 입력을 하거나 창의 상태가 변경되면 시스템은 특정 창에 메시지를 보냅니다. 예를 들어 메뉴가 전송되면 WM_COMMAND 메시지가 전송됩니다. WPARAM의 상위 워드(HIWORD(wParam))는 해당 메뉴의 메뉴 ID인 명령의 ID 번호입니다. 물론 사용자는 자신의 메시지 이름을 정의하거나 사용자 정의 메시지를 사용하여 알림을 보내고 데이터를 전송할 수도 있습니다.

2) 메시지를 받는 사람 : 메시지는 창을 통해 받아야 합니다.

윈도우 프로세스(WNDPROC)에서는 메시지를 분석하고 관심 있는 메시지를 처리할 수 있습니다. 예를 들어, 메뉴 선택을 처리하려면 WM_COMMAND를 처리하도록 코드를 정의하면 창에서 그래픽 출력을 수행하려면 WM_PAINT를 처리해야 합니다.

3) 처리되지 않은 메시지는 어디로 가나요? M$는 창에 대한 기본 창 프로시저를 작성합니다. 이 창 프로시저는 처리하지 않은 메시지를 처리하는 역할을 합니다. 우리가 창의 다양한 메시지 처리에 너무 많은 주의를 기울이지 않고도 개발을 위해 Windows 창을 사용할 수 있는 것은 바로 이 기본 창 프로세스 때문입니다. 예를 들어, 창을 드래그할 때 많은 메시지가 전송되지만 이를 무시하고 시스템이 자체적으로 처리하도록 할 수 있습니다.

4) 창 핸들: 메시지를 이야기할 때 창 핸들을 빼놓을 수 없습니다. 시스템은 창 핸들을 사용하여 전체 시스템에서 창을 고유하게 식별해야 합니다. 메시지가 어느 창에서 수신되었는지 나타내기 위해 지정됩니다. 각 창에는 자체 창 프로시저가 있으므로 사용자 입력이 올바르게 처리됩니다. 예를 들어 하나의 창 프로시저 코드를 사용하는 두 개의 창이 있는 경우 창 1에 마우스를 클릭하면 메시지가 창 1의 핸들을 통해 창 2가 아닌 창 1로 전송됩니다.

3. 메시지 소스

이벤트 중심 이벤트는 메시지 생성 및 처리를 중심으로 진행됩니다. 이벤트 기반은 메시지 루프 메커니즘으로 구현됩니다. 메시지는 관련 이벤트가 발생했음을 알리는 알림이라고 이해할 수도 있습니다.

Windows 애플리케이션에는 네 가지 메시지 소스가 있습니다.

1) 입력 메시지: 키보드 및 마우스 입력을 포함합니다. 이러한 유형의 메시지는 먼저 시스템 메시지 큐에 배치된 다음 Windows에서 해당 메시지를 애플리케이션 메시지 큐로 보내고 애플리케이션이 메시지를 처리합니다.

2) 제어 메시지: 목록 상자, 버튼, 체크 상자 등과 같은 Windows 제어 개체와의 양방향 통신에 사용됩니다. 이 메시지는 사용자가 목록 상자에서 현재 선택 항목을 변경하거나 확인란의 상태를 변경할 때 표시됩니다. 이러한 유형의 메시지는 일반적으로 애플리케이션 메시지 큐를 통과하지 않고 제어 개체로 직접 전송됩니다.

3) 시스템 메시지: 프로그래밍된 이벤트 또는 시스템 클럭 인터럽트에 응답합니다. DDE 메시지(Dynamic Data Exchange 메시지)와 같은 일부 시스템 메시지는 Windows 시스템 메시지 대기열을 통과하는 반면 일부는 창 메시지 생성과 같이 시스템 메시지 대기열을 거치지 않고 응용 프로그램의 메시지 대기열로 직접 전송됩니다.

4) 사용자 메시지 : 프로그래머가 직접 정의하여 애플리케이션에서 적극적으로 발행하는 메시지로 일반적으로 애플리케이션의 특정 부분에서 내부적으로 처리됩니다.

4. Windows 메시지 시스템의 구성

Windows 메시지 시스템은 다음 세 부분으로 구성됩니다.

메시지 큐: Windows는 모든 애플리케이션에 대해 이를 유지할 수 있습니다. 메시지 대기열, 애플리케이션은 메시지 대기열에서 메시지를 가져온 다음 이를 양식으로 전달해야 합니다.

메시지 루프: 이 루프 메커니즘을 통해 애플리케이션은 메시지 대기열에서 메시지를 검색하고 이를 적절한 창으로 전달한 후 계속해서 메시지 대기열에서 다음 메시지를 검색하여 적절한 창으로 전달합니다. 창. 순서대로 진행합니다.

창 프로시저: 각 창에는 Windows가 창에 전달한 메시지를 수신하는 창 프로시저가 있습니다. 창 프로시저의 작업은 메시지를 얻고 이에 응답하는 것입니다. 윈도우 프로시저는 일반적으로 메시지를 처리한 후 Windows에 값을 반환하는 콜백 함수입니다.

5. 메시지 응답

메시지는 시스템 이벤트(타이머 이벤트 포함) 및 사용자 이벤트에서 생성됩니다. Windows는 메시지를 사용하여 로드 및 닫기(및 창 그리기 등의 기타 처리)를 수행합니다. 등) 응용 프로그램의 일반적인 성능은 종료 작업 중에 Windows가 실행 중인 모든 응용 프로그램에 종료 메시지를 보내 메모리를 종료하라는 메시지를 보내는 것입니다. 따라서 메시지는 애플리케이션이 WinOS와 상호 작용하는 수단입니다.

메시지 생성부터 창 응답까지의 단계: (아래 참조)

1> 시스템이 발생했습니다. 또는 사용자가 특정 이벤트를 발행했습니다.

2> Windows는 이 이벤트를 메시지로 변환한 다음 메시지 대기열에 넣습니다.

3> 애플리케이션은 메시지 대기열에서 이 메시지를 수신하여 TMsg 녹음에 저장합니다. .

4> 애플리케이션은 메시지를 적절한 양식 프로시저에 전달합니다.

양식 프로시저는 이 메시지에 응답하고 이를 처리합니다. 메시지는 이 양식의 양식 기능으로 전달됩니다.

3. Windows 메시지 메커니즘의 핵심 사항

1. 윈도우 프로시저

각 윈도우에는 윈도우 프로시저라고 불리는 콜백 함수(WndProc)가 있습니다. 창 핸들(Window Handle), 메시지 ID(Message ID) 및 두 개의 메시지 매개 변수(wParam, lParam)라는 네 가지 매개 변수가 있습니다. 창이 메시지를 받으면 시스템은 이 창 프로시저를 호출하여 메시지를 처리합니다. (그래서 콜백 함수라고 부릅니다)

2가지 메시지 유형

1) 시스템 정의 메시지

SDK에서 미리 정의한 메시지, Non- 사용자 정의, 범위는 [0×0000, 0×03ff] 사이이며 다음 세 가지 범주로 나눌 수 있습니다:

창 메시지(Windows 메시지)

창 포함 창 생성, 창 그리기, 창 파괴 등 내부 작업과 관련됩니다. 일반 창, 대화 상자, 컨트롤 등이 될 수 있습니다.

예: WM_CREATE, WM_PAINT, WM_MOUSEMOVE, WM_CTLCOLOR, WM_HSCROLL..

명령 메시지(Command Message)

클릭 등 사용자 요청 처리와 관련 항목이나 도구 모음 또는 컨트롤을 선택하면 메뉴 명령 메시지가 생성됩니다.

WM_COMMAND, LOWORD(wParam)은 메뉴 항목, 도구 모음 버튼 또는 컨트롤의 ID를 나타냅니다. 컨트롤인 경우 HIWORD(wParam)은 컨트롤 메시지 유형을 나타냅니다.

컨트롤 알림(Notify Message)

컨트롤 알림 메시지는 가장 유연한 메시지 형식입니다. wParam, lParam WM_NOTIFY, 컨트롤 ID, NMHDR에 대한 포인터입니다. NMHDR에는 제어 알림 내용이 포함되어 있으며 임의로 확장할 수 있습니다.

2) 애플리케이션 정의 메시지

사용자 정의 메시지에는 해당 범위에 대해 다음 조항이 있습니다:

WM_USER: 0×0400 -0×7FFF (예: . WM_USER+10)

WM_APP(winver>4.0): 0×8000-0xBFFF (ex.WM_APP+4)

RegisterWindowMessage: 0xC000-0xFFFF

3 메시지 큐

Windows에는 두 가지 유형의 메시지 큐가 있습니다.

1) 시스템 메시지 큐(System Message Queue)

시스템 전용 큐입니다. 장치 드라이버(마우스, 키보드)는 작업 입력을 메시지로 변환하여 시스템 대기열에 저장합니다. 그런 다음 시스템은 해당 메시지를 대상 창이 있는 스레드의 메시지 대기열에 넣습니다(스레드별). . 메시지 큐)

2) 스레드별 메시지 큐

각 GUI 스레드는 이러한 스레드 메시지 큐를 유지합니다. (이 큐는 스레드가 GDI 함수를 호출할 때만 생성되며 기본적으로 생성되지 않습니다.)

그런 다음 스레드 메시지 큐의 메시지는 처리를 위해 해당 창 프로시저(WndProc)로 전송됩니다.

참고: 스레드 메시지 큐의 WM_PAINT 및 WM_TIMER는 다른 메시지가 없을 때만 처리됩니다. WM_PAINT 메시지도 병합되어 효율성이 향상됩니다. 다른 모든 메시지는 FIFO(선입선출) 방식으로 처리됩니다.

4개의 대기열에 있는 메시지 및 대기열에 없는 메시지

1) 대기열에 있는 메시지

메시지가 먼저 저장됩니다. 메시지 대기열에서 메시지 루프가 메시지를 가져옵니다. 이 대기열에서 마우스 및 키보드 메시지와 같은 처리를 위해

각 창에 배포합니다.

2) 대기열에 없는 메시지

메시지는 시스템 메시지 대기열과 스레드 메시지 대기열을 우회하고 처리를 위해 창 프로세스로 직접 전송됩니다.

예: WM_ACTIVATE , WM_SETFOCUS, WM_SETCURSOR, WM_WINDOWPOSCHANGED

참고: postMessage가 보낸 메시지는 메시지 대기열에 메시지를 게시하는 대기열 메시지입니다. SendMessage가 보낸 메시지는 대기열이 아닌 메시지입니다. 처리를 위해 윈도우 프로시저로 전송됩니다.

5가지 Windows 메시지 기능

1) PostMessage(PostThreadMessage), SendMessage

PostMessage: 메시지를 스레드 메시지 대기열에 넣습니다. 지정된 창이 있는 곳에서 즉시 반환됩니다. PostThreadMessage: 지정된 스레드의 메시지 대기열에 메시지를 넣은 후 즉시 반환합니다.

SendMessage: 처리를 위해 메시지를 창 프로시저로 직접 보내고 처리가 완료된 후에만 반환합니다.

2) GetMessage, PeekMessage

PeekMessage는 즉시 반환되며 메시지는 보관될 수 있습니다.

GetMessage는 메시지가 있을 때 반환되면 메시지를 삭제합니다

3 ) TranslateMessage, TranslateAccelerator

TranslateMessage: 가상 키 메시지를 문자 메시지(문자 메시지)로 변환하여 현재 스레드의 메시지 큐에 넣습니다. 처리를 위해 메시지 루프가 제거됩니다.

TranslateAccelerator: 단축키를 해당 메뉴 명령에 매핑합니다. WM_KEYDOWN 또는 WM_SYSKEYDOWN을 바로 가기 키 테이블의 해당 WM_COMMAND 또는 WM_SYSCOMMAND 메시지로 변환한 다음 변환된 WM_COMMAND 또는 WM_SYSCOMMAND를 처리를 위해 창 프로시저로 직접 보내고 처리 후 반환됩니다.

6개의 메시지 교착 상태

스레드 A와 B가 있다고 가정하면 이제 다음 단계가 있습니다.

1) 스레드 A 스레드 B로 메시지 보내기, A 대기 스레드 B에서 처리한 후 반환할 메시지

2) 스레드 B는 스레드 A로부터 메시지를 받아 처리합니다. 처리하는 동안 B도 스레드 A에 메시지를 보낸 다음 스레드 A의 반환을 기다립니다. 에이.

이때 쓰레드 A는 쓰레드 B의 복귀를 기다리고 있어 B가 보낸 메시지를 처리할 수 없어 쓰레드 A와 B가 서로를 기다리게 되어 교착상태가 발생하기 때문이다. 여러 스레드가 순환 교착 상태를 형성할 수도 있습니다.

교착 상태를 방지하려면 SendNotifyMessage 또는 SendMessageTimeout을 사용할 수 있습니다.

7 BroadcastSystemMessage

우리가 일반적으로 접하는 메시지는 실제로 메시지를 받는 사람이 다양할 수 있고, 애플리케이션일 수도 있습니다. , 설치 가능한 드라이버, 네트워크 드라이버, 시스템 수준 장치 드라이버 등

BroadcastSystemMessage는 위의 시스템 구성 요소에 메시지를 보낼 수 있는 API입니다.

그럼 이 메시지는 어떻게 전송되나요? 메시지 전송 프로세스를 살펴보기 위해 MFC를 예로 들어 보겠습니다.

4. MFC 메시지 메커니즘

Windows 애플리케이션의 주요 기능에서는 먼저 창 클래스를 등록한 다음 창을 생성하고 표시해야 합니다. 창을 만든 후 프로그램은 메시지 루프에 들어가며 메시지 루프에서 계속해서 메시지를 얻고 처리를 위해 해당 메시지를 해당 창 함수로 전달합니다.

MFC 프레임워크에서 메시지 처리를 수행할 수 있는 클래스의 헤더 파일에는 주로 메시지 매핑 및 메시지 처리를 수행하는 DECLARE_MESSAGE_MAP() 매크로가 포함되어 있음을 알 수 있습니다.

. 메시지 처리를 수행할 수 있는 클래스의 구현 파일은 일반적으로 다음과 같은 구조를 포함합니다.

BEGIN_MESSAGE_MAP(CInheritClass, CBaseClass) //{{AFX_MSG_MAP(CInheritClass)

//}}AFX_MSG_MAP

END_MESSAGE_MAP()

여기서는 주로 메시지 매핑과 메시지 처리 기능을 구현합니다.

메시지 처리를 수행할 수 있는 모든 클래스는 CCmdTarget 클래스를 기반으로 합니다. 즉, CCmdTarget 클래스는 메시지 처리를 수행할 수 있는 모든 클래스의 상위 클래스입니다. CCmdTarget 클래스는 MFC 처리 명령 메시지의 기초이자 핵심입니다.

동시에 MFC는 다음 두 가지 주요 구조를 정의합니다.

AFX_MSGMAP_ENTRY

struct AFX_MSGMAP_ENTRY

{//""" //

};

및 AFX_MSGMAP

구조체 AFX_MSGMAP

{//""``//

};

AFX_MSGMAP_ENTRY 구조에는 메시지의 모든 관련 정보가 포함되어 있으며 AFX_MSGMAP에는 두 가지 주요 기능이 있습니다. 하나는 기본 클래스의 메시지 매핑 항목 주소를 얻는 데 사용됩니다. 2: 자신만의 메시지 매핑 항목 주소를 얻으세요.

사실 MFC는 모든 메시지를 AFX_MSGMAP_ENTRY 구조에 하나씩 채워 모든 메시지와 관련 메시지 매개 변수를 저장하는 배열을 형성합니다. 동시에 AFX_MSGMAP을 통해 배열의 첫 번째 주소를 얻을 수 있고, 기본 클래스의 메시지 매핑 항목 주소도 얻을 수 있습니다. 이는 해당 기본 클래스가 응답하지 않을 때 메시지 응답을 호출하는 예입니다. 메시지에.

이제 MFC에서 창 프로시저가 메시지를 처리하도록 허용하는 방법을 분석해 보겠습니다. 실제로 모든 MFC 창 클래스는 후크 함수 _AfxCbtFilterHook를 통해 메시지를 가로채고 AfxWndProc에 대한 후크 함수 _AfxCbtFilterHook에 창 프로시저를 설정합니다. 원래 창 프로시저는 m_pfnSuper 멤버 변수에 저장됩니다.

1. MFC 프레임워크에서 Windows로부터 메시지를 수신하고 처리하는 프로세스:

2. /p>

MFC가 게시된 메시지를 받습니다.

MFC가 게시된 메시지를 처리하는 것과 메시지를 보내는 것 사이의 유일한 중요한 차이점은 게시된 메시지가 애플리케이션의 메시지 큐에서 일정 시간을 보낸다는 것입니다.

메시지 펌프가 이를 팝할 때까지 대기열에 남아 있습니다. 보낸 메시지를 수락하는 방법은 다음과 같습니다. MFC 애플리케이션의 메시지 펌프는 CWinApp의 Run() 멤버 함수에 있습니다. 응용 프로그램이 실행되기 시작하면 Run()이 호출되어 시간을 두 부분으로 나눕니다. 한 부분은 임시 CWnd 개체 취소와 같은 백그라운드 처리를 수행하는 데 사용되며 다른 부분은 메시지 대기열을 확인하는 데 사용됩니다. 새 메시지가 들어오면 Run()은 이를 추출합니다. 즉, GetMessage()를 사용하여 대기열에서 메시지를 제거하고 두 개의 메시지 변환 함수 PreTranslateMessage() 및 ::TranslateMessage()를 실행한 다음 DispatchMessage( ) 메시지가 의도된 창 프로세스입니다. 아래 그림과 같습니다.

MFC의 내부 메시지 처리 과정을 살펴보기 위해 인스턴스 함수 A를 사용하여 함수 B에 메시지를 보냅니다.

1. 먼저 함수 A는 메시지의 CWnd 클래스 개체의 포인터를 얻은 다음 CWnd의 SendMessage() 멤버 함수를 호출해야 합니다.

LRESULT Res=pWnd->SendMessage(UINT Msg, WPARAM wParam, LPARAM lParam);

pWnd 포인터는 대상 CWnd 클래스 개체를 가리킵니다. Msg 변수는 메시지이고, wParam 및 lParam 변수에는 마우스가 클릭된 위치나 선택된 메뉴 항목과 같은 메시지의 매개변수가 포함됩니다. 대상 창에서 반환된 메시지 결과는 Res 변수에 저장됩니다.

CWnd 함수 개체가 없는 창에 메시지를 보내려면 다음 대상 창 핸들을 사용하여 Windows API를 직접 호출할 수 있습니다.

LRESULT Res=::SendMessage (HWND hWnd, UINT Msg , WPARAM wParam, LPARAM lParam);

여기서 hWnd는 대상 창의 핸들입니다.

비동기 전송인 경우 PostMessage()를 사용할 수도 있습니다. 메시지는 위와 동일하지만 반환 값 Res는 대상 양식에서 반환되는 값이 아니라 a입니다. 메시지를 나타내는 데 사용되는 부울 값입니다. 메시지 대기열에 성공적으로 추가되었는지 여부입니다.

2. 일반적인 상황에서는 메시지가 전송되면 애플리케이션 백그라운드에서 자동으로 메시지를 보내지만, 특별한 상황에서는 메시지를 직접 삭제해야 합니다. 애플리케이션 어떤 종류의 메시지가 나타나기 전에 애플리케이션을 중지하십시오. 애플리케이션 메시지 큐에서 메시지를 삭제하는 방법에는 두 가지가 있지만 이러한 방법 중 어느 것도 MFC와 관련이 없습니다.

첫 번째 방법: 아무것도 방해하지 않고 메시지가 있는지 확인하기 위해 메시지 대기열을 들여다보세요.

BOOL res=::PeekMessage(LPMSG lpMsg, HWND hWnd, UINT wMsFilterMin, UINT wMsgFilterMax, UINT wRemoveMsg ) ;

두 번째 방법: 새 메시지가 도착할 때까지 실제로 기다립니다. 큐에서 메시지는 삭제되고 반환됩니다.

BOOL res=::GetMessage(LPMSG lpMsg, HWND hWnd, UINT wMsgFilterMin, UINT wMsgFilterMax);

이 두 가지 방법에서 변수 hWnd는 메시지를 가로챌 창을 지정합니다. 이 변수가 NULL로 설정되면 모든 창 메시지가 차단됩니다. wMsgFilterMin 및 wMsgFilterMax 변수는 SendMessage()의 변수 Msg에 해당하며 표시할 메시지의 범위를 지정합니다. "0,0"을 사용하면 모든 메시지가 차단됩니다.

WM_KEYFIRST, WM_KEYLAST 또는 WM_MOUSEFIRST, WM_MOUSELAST를 사용하면 모든 키보드 또는 마우스 메시지가 차단됩니다. wRemoveMsg 변수는 PeekMessage()가 실제로 큐에서 메시지를 제거해야 하는지 여부를 지정합니다. (GetMessage()는 항상 메시지를 삭제합니다). 이 변수는 두 가지 값을 가질 수 있습니다:

PM_REMOVE, PeekMessage()는 메시지를 삭제합니다.

PM_NOREMOVE, PeekMessage()는 메시지를 대기열에 남겨두고 복사본을 반환합니다.

물론, 메시지 대기열에 메시지를 남겨둔 다음 동일한 유형의 메시지를 보기 위해 PeekMessage()를 다시 호출하면 정확히 동일한 메시지가 반환됩니다.

lpMsg 변수는 검색된 메시지가 포함된 MSG 구조에 대한 포인터입니다.

typedef struct tagMSG {

HWND hwnd; // 창 핸들 메시지는

UINT 메시지를 위한 것입니다;

WPARAM wParam;

LPARAM lParam;

DWORD time; // 메시지가 대기열에 들어간 시간

POINT pt;

// 메시지가 대기열에 저장되었습니다.

} MSG;

3. 메시지가 메시지 대기열에 저장됩니다. CwinApp의 멤버 함수인 Run은 애플리케이션이 실행되는 시간을 두 부분으로 나눕니다. 한 부분은 백그라운드 처리를 수행하고, 다른 부분은 메시지 큐를 확인합니다. 새 메시지가 발견되면 Run은 큐에서 메시지를 검색하기 위해 GetMessage()를 호출합니다. . 메시지를 검색합니다.

3. 번역을 위해 두 가지 메시지 번역 함수 PreTranslateMessage() 및 ::TranslateMessage()를 실행합니다. 주로 함수 개체의 위치, 메시지의 작업 식별자 및 메시지와 관련된 실행 작업을 찾습니다.

4. DispatchMessage() 함수를 사용하여 메시지의 예상되는 함수 B 프로세스를 호출하고 실행합니다.