C# で記述された Windows フォーム アプリケーションを C++ Windows アプリケーションに埋め込む方法を探しています。ネイティブ アプリケーションのメイン ウィンドウは、複数のペインに分割されています。C# アプリケーションは、これらのペインの 1 つに表示されるはずです。つまり、C# コンポーネントのルート ウィンドウ (最も外側のフォーム) は、メイン アプリケーションの子ウィンドウでなければなりません。
これはできますか？もしそうなら、どのように？
追加のコンテキスト: 私の知る限り、これには 2 つの方法があります。まず、.net ホスティング API (ICLRRuntimeHost など) を使用して、ネイティブ アプリで CLR をホストします。次に、Windows フォームを ActiveX コントロールに配置して、CLR をホストします。
最初のアプローチに関しては、CLR を起動して C# アセンブリをロードすることができました (主にMattias Högströmに感謝します)。私が障害にぶつかっているのは、CLR で実行しているコンポーネントに、C++ 側から渡されたウィンドウの子である必要があることを伝える方法がないことです。
私は 2 番目の方法も試しました (ActiveX を使用し、Daniel Yanovskyに感謝します)。それはほとんど、しかしほとんど、私の目的のために機能します。ネイティブ アプリの子ペインで任意の Windows フォーム コンポーネントを実行できます。しかし、それらは常にメインアプリのメインスレッドで実行されます。これは、メイン アプリの Windows メッセージ ループを使用することを意味します。MSDN は、標準の Windows メッセージ ループが Windows フォームの要件を満たしていないため、これは確実に機能しないと述べています (MSDN へのリンクをここに投稿したかったのですが、新しいユーザーの 2 つのリンク割り当てを既に使い果たしています)。
MSDN、Internet Explorer、および MFC アプリによると、メッセージ ループの問題の例外は次のとおりです。私がホストとして使用しているネイティブ アプリは、間違いなく Internet Explorer ではありません。また、wxWidgets によってラップされた Windows API を使用するため、MFC はオプションではありません (少なくとも歓迎されません)。
Microsoft が提案するソリューションには、C# コンポーネントを独自のスレッドの独自のメッセージ ループで実行させることが含まれます。これは、少なくとも私が知る限り、必然的に上記の最初のアプローチにつながります。そこで、渡された親ウィンドウの下で Windows フォームを機能させるという問題に戻ります。
繰り返しますが、ここで言及したアプローチとは関係なく、子ウィンドウの問題を明確にする入力に興味があります。しかし、コンテキストに照らして、一般的な質問を 2 つの具体的な質問に減らすことができます (そのうちの 1 つだけに回答する必要があります)。
- Windows フォームが ActiveX コントロールでホストされている場合、フォームを独自のスレッドの独自のメッセージ ループで実行できるようにするにはどうすればよいですか?
また
- ネイティブ アプリによってホストされている CLR で実行されている Windows フォームがある場合、そのフォームをネイティブ アプリのウィンドウの子ウィンドウにするにはどうすればよいですか?