2016-10-18 10 views
-2

내 app1 PostMessage WM_LBUTTONDOWN 및 WM_LBUTTONUP을 (를) 다른 프로세스 인 app2 (타사)에 전달합니다.다른 응용 프로그램에서 PostMessage를 처리하는 방법은 무엇입니까?

이러한 메시지가 app1의 app2에 의해 처리되었는지 확인하려면 app1의 논리는 PostMessage 이후의 메시지 결과에 따라 달라집니다.

여기에 비동기 적으로 APP1

PostMessage(app2Handle, WM_LBUTTON_DOWN, 0, lParam); 
PostMessage(app2Handle, WM_LBUTTON_UP, 0, lParam); 
// How to ensure above messages has been handled by app2 here? 
+0

메시지를 처리 ​​할 때 다른 앱에서 사용자에게 알리도록하십시오. 어쨌든 왜 자동화를 사용하지 않습니까? –

+0

UI 자동화는 비활성 창에 대한 신뢰도가 높지 않습니다. 즉 TreeView 항목을 클릭하면 창이 활성 상태 여야합니다. 그래서 win32 API로 전환했습니다. – user1633272

+1

그건 완전히 난센스입니다. UI 자동화 **는 타겟 창이 활성화되어 있는지 여부에 관계없이 신뢰할 수 있습니다. 어쨌든 [Replaying input은 다시 처리하는 것과 같지 않습니다.] (https://blogs.msdn.microsoft.com/oldnewthing/20121206-00/?p=5903) 및 [PostMessage로 키보드 입력을 시뮬레이션 할 수 없습니다] (https://blogs.msdn.microsoft.com/oldnewthing/20050530-11/?p=35513/), 이것이 작동하지 않는 이유를 이해하십시오. – IInspectable

답변

1

PostMessage() 작품에 대한 의사 코드입니다. 단순히 대상 창 메시지 대기열에 메시지를 넣은 다음 즉시 종료합니다. 메시지가 처리 될 때 알림이 없습니다. 이 사실을 알아야 할 경우 SetWindowsHookEx()의 메시지 후크를 사용하여 대상 창의 메시지 대기열 및/또는 창 프로 시저의 활동을 모니터링 할 수 있습니다. 또는 SetWinEventHook()을 사용하여 EVENT_OBJECT_INVOKED, EVENT_OBJECT_SELECTION... 등과 같은 이벤트를 수신 할 수 있습니다. 마우스 메시지가 창에서 이러한 클릭/선택 작업을하도록 의도 된 경우입니다.