私は2009年3月のDirectX SDKでDirect3DアプリケーションのDXUT関数を試してきました。 Direct3DやDirectX9の自動検出や、Direct3Dが一般的に必要とする面倒なウィンドウ管理タスクをバイパスするウィンドウ管理機能など、多くの便利な機能を備えているようです。しかし、私はDXUTSetWindow関数を使ってDirect3Dを既に作成されたウィンドウに描画するときに問題があります。この場合、アプリケーションのメインウィンドウであるビューの子ウィンドウはCFrameWndExです。DXUTSetWindowをMFC Direct3Dアプリケーションで使用する
bHandleMessagesパラメータをtrueに設定すると、すべてが自分の部分に干渉することなくサイズが変更され、リセットされます。しかし、プログラムを終了しようとするとアプリケーションがクラッシュし（すぐに終了するので、クラッシュの原因を調べることさえできず）、メモリリークが発生します。 bHandleMessagesをfalseに設定した場合、サイズ変更は行われませんが、終了時にクラッシュやメモリリークは発生しません。
WM_QUITメッセージを探して終了し、子ウィンドウで受信されないDirect3Dオブジェクトをすべてクリーンアップするように見えます。私が試したなしの成功と、次の
CFrameWndExのOnClose機能をオーバーライドし、手動で子供にWM_QUITメッセージを送信します。- ワーカースレッドで
DXUTMainLoop呼び出しを行う。 CFrameWndEx::DefWindowProcをオーバーライドし、DXUTStaticWndProc関数を使用します（DXUTドキュメントではDXUTSetWindowを使用する場合には使用するように指定されていますが、いずれの例にも表示されません）。CFrameWndExのハンドルを使用し、子ウィンドウ用に別のスワップチェーンを作成するようにウィンドウを設定します。 OnD3D9FrameRenderコールバックで何かが行われたかどうかにかかわらず、DXUTはDXUTSetWindowで使用されているハンドルを黒くするようです。
UPDATE：子ウィンドウのDefWindowPro Cをオーバーライドして、子ウィンドウのDefWindowProcからDXUTStaticWndProcを呼び出した後、私は、メモリリーク、実行するアプリケーションを取得し、サイズ変更、クラッシュせずに失われたデバイス、および終了を処理することができました。これは、bHandleMessagesをfalseに設定して行われます。ただし、これにより新しい問題が発生します。
Direct3Dの描画面は、子ウィンドウの領域よりも2ピクセル小さく、描画面を囲むビデオノイズの境界が残ります。同じDXUTStaticWndProc機能の同じHWNDで動作しているにもかかわらず、bHandleMessagesが真の場合、これは発生しません。
更新2：ピクセルの問題が解決されたようです。
LRESULT ChildView::DefWindowProc(UINT message, WPARAM wParam, LPARAM lParam){
LRESULT lr = DXUTStaticWndProc(this->GetSafeHwnd(), message, wParam, lParam);
if(lr != 0) {
return CWnd::DefWindowProcW(message, wParam, lParam);
}
return lr;
}
：この質問への最初の更新からスキームを使用して、私はDXUTStaticWndProc次のコードは、それを解決するように見えるので、0を返さなかった場合にのみ上書き子ウィンドウのDefWindowProcでCWnd::DefWindowProcを呼び出すだけに必要な発見しました私の他の質問はまだありますが、DXUTライブラリを使用する価値はありますか？ DirectXを使って私ができることはどれくらい制限されますか？すべてのDirect3Dオブジェクトの管理、デバイスのセットアップ/リセット、レンダリングを手動で行うだけに戻すべきでしょうか？