4

WindowsFormsHost コントロールにラップされた Windows フォーム ベースのコントロールで発生していたメモリ リークの問題を解決するために System.AddIn を使用している WPF アプリケーションに取り組んでいます。アドインは、WindowsFormsHost のオーバーヘッドを回避するために、必要に応じて Windows フォーム ベースのコントロールをロードおよびアンロードするために使用されます。このオーバーヘッドは、WPF の現在のバージョンでアプリケーションが閉じられるまでハングアップし、Windows フォーム ベースのコントロールでメモリ リークが発生します。クリーンアップ ロジックが正しくありません。

私たちが直面している問題は、アプリケーションでアドインをロードおよびアンロードした後、WPF アプリケーションがアプリケーションの終了時に「無効なウィンドウ ハンドル」の Win32 例外をスローすることです。これは通常、重大な懸念事項ではありませんが、例外をキャッチすることは可能ですが、Windows がアプリケーションをクラッシュしたと認識し、Windows 7 でクラッシュ ダイアログを表示するのを止めることはできず、これは容認できません。

コードに関して、関連する事実は次のとおりです。

  1. この例外は、アドインが WPF ホスト アプリケーションによってロードおよびアンロードされた場合にのみ発生します。アドインをアンロードする前に呼び出されるカスタム Dispose メソッドの一部として、アドイン内の WindowsFormsHost コントロールと Windows フォーム ベースのコントロールを破棄します。

  2. アドインはアンロードの前に (上記の破棄プロセスの一部として) ディスパッチャをシャットダウンしています。これは、MSDN のドキュメントとブログの投稿に記載されていたものであり、この問題を解決するために必要でしたが、この場合は発生しませんでした。

  3. 一部のレポートには Windows フォーム ベースのコントロールが必要であり、変換するレポート ファイルが多すぎ、適切な WPF バージョンがなく、変更する時間がないため、Windows フォーム ベースのコントロールを使用する選択肢はありません。

私はコードのサンプルを提供することができないので、私が見逃したものがある場合に備えて、そのようなシナリオでの考えや以前の経験に手を差し伸べています.

4

1 に答える 1

2

少し前に同様の問題がありました。メイン ウィンドウのイベント ハンドラーでDispatcher.InvokeShutdown(コントロールのコンテンツが null でないことをテストした後)呼び出していることがわかり、それが解決策だったことを思い出すようです。Window_Closing

于 2010-07-21T20:09:48.887 に答える