ui 메시지를 펌핑하는 동안 추가 이벤트를 잡기 위해 MsgWaitForMultipleObjects를 사용하여 메시지 루프하는 응용 프로그램이 있습니다. 창을 이동하거나 크기를 조정하자 마자 DefWindowProc는 마우스가 해제 될 때까지 자체 메시지 루프를 시작합니다. 이 상황은 외부 루프가 추가 메시지를 포착하는 것을 방지합니다.윈도우 이동 및 크기 조정이 MsgWaitForMultipleObjects와 충돌합니다.
나는 이것 때문에 응용 프로그램을 멀티 스레드하는 것을 싫어합니다. 그것을 해결할 다른 방법이 있습니까?
Windows API에 자체 메시지 루프를 입력하는 몇 가지 추가 위치가 있습니다. 이 시간 동안 계속 메시지를 처리해야하는 경우 별도의 스레드가 필요합니다.
MsgWaitForMultipleObjects는 전통적인 멀티 스레드 프로그램에서 거의 사용되지 않습니다. 그것은 전통적인 비 클라이언트 프레임 요소가 생략되고 "MessageBox"및 "DoDragDrop"와 같은 API가 생략되는 게임에서 일부 사용이 있습니다 ...
보통 "UI 작업자"스레드에서는 사용하지 않는 것이 가장 좋습니다 보이지 않는 창을 호스트하지만 메시지 대기열을 인터 스레드 메시징 시스템으로 사용하고 커널 핸들을 기다려야합니다.
두 번째 스레드를 만드는 것은 피할 수없는 것처럼 보일 수 있습니다. 역설적이게도, PostThreadMessage + MsgWaitForMultipleObjects는 아마도 GUI 스레드와 "ui"작업자 스레드간에 안정적인 통신 메커니즘을 설정하는 가장 쉬운 방법 일 것입니다.