4개월이 흐르는 동안 가끔식 이슈가 떠오를 때마다 관련글을 찾아보았지만 현재 문제가 되고 있는 부분을 깔끔하게 해결하지 못하고 있다.
Unmanaged Application인 MFC응용 프로그램에서 Windows Form Control을 Hosting하고 Form Control에서 발생하는 Message의 Overhead를 Form Control을 생성하는 별도 메시지 루프를 가진 스레드를 생성하여 MFC 응용프로그램 자체에서 해결할려고 줄기차게 시도하였다.
그러나 스레드간 메시지 전달에 있어 많은 문제가 발생하였다. 따라서 해결책은 이하 .NET Framework에서 메시지 루프를 생성하여 Overhead를 극복하는 방법밖에 없는 듯 하다.
이 주제에 대해 차분한 정리가 필요할 듯 하다. (구글 검색 키워드 : com interop message loop form control)
Managed Extensions for C++를 사용하여 MFC에서 .NET Framework Windows Forms 컨트롤 호스팅 Windows Forms 컨트롤을 MFC 뷰 클래스로 사용 MFC 명령 라우팅 인프라를 Windows Forms 컨트롤로 확장 .NET Framework 사용자 지정 특성을 사용하여 명령 처리기 및 명령 UI 업데이트 처리기 지정
MSDN의 예제를 따라 개별 스레드에서 .NET 메시지 루프를 생성하는 것을 간단히 테스트 해 보았으나, 이것의 문제는 Form 창이 별도의 모달로 뜬다는 것이다. 내가 원하는 것은 "Windows Form Control을 MFC에서 창 객체에 embedded 하고, Form Control을 위한 별도의 메시지 루프를 두는 것" 이다.
다음으로 테스트는 Form이 아닌 Form Control을 .NET 스레드에서 생성하고 Application.Run을 통해 메시지 루프를 돌린 후 MFC에서는 스레드에서 생성된 Form Control을 받아와 Hosting을 해주었다. 동작에는 이상이 없으나, --; 메시지가 Main MFC로 넘어왔다.
아! 역시 확실한 방법이 없다. 현재 쓰는 Windows Form Control의 메시지 처리 오버헤드가 너무 심하다. --;
기본적으로 UI Thread 라는 관점에서 접근해야 할 듯 하다. Multithreaded Applications using MFC : 전체적으로 CWinThread에 대해 다루고 있다. 스레드의 기본적인 것도 다루지만 UI 스레드를 생성하는 것도 잠깐 언급한다. 이건 입문 수준
기타 CWinThread로 UI 스레드를 생성하는 것과 주의점에 대해 다루는 문서들이 있다.
