WindowsFormsHostをWPFで表示したときの問題

Windows用ソフトの開発で無駄に引っかかったのでメモ

WPF内にWindowsFormsHostを入れてはいけない

WPF内でもちゃんと拡縮を設定してやりさえすれば表示自体は問題なく成功する(サイズ変更をしているだけなので当たり前)
問題はScrollviewerなどの実際にView自体は拡縮されずクリッピングして表示するビューの場合。
WidnowsFormsHostの表示がWPFのアイテムの上に表示されてしまう。

• ハイブリッド アプリケーションのトラブルシューティング
  • https://docs.microsoft.com/ja-jp/dotnet/framework/wpf/advanced/troubleshooting-hybrid-applications#overlapping-controls

WPFでホストされるWindowsフォームコントロールは、常にWPFコンテンツの上に表示されます。

WPFが表示順序でWindowsFormsHostに負けるのは仕様でした。

対処方法

• WPFでWindowsFormsHostを使わない
  • 既存があるからと言って使ってもろくなことになりません
    移植する場合はおとなしくWPFに書き換えるほうが無難

どうしても使いたい

まだ現実的な方法

• WPFのアイテムにかぶらないようにレイアウトする
  • GridやStackPanelみたいないい感じに並べてくれるやつに入れる
• Scrollviewerのようなクリッピングで表示制限をするようなオブジェクトに入れない

できればやりたくない方法

• リサイズイベントで制御する
  • Scrollviewerの場合、スクロールさせるとめり込むので、表示領域より小さく表示させる必要がある
    Scrollviewerに入っているにもかかわらずスクロールしないという気持ち悪いものができてしまう
• クリッピングを自前で作って頑張る
  • できるかどうかは知らないが、表示領域や、スクロール位置、更に上の階層の表示領域とスクロール位置...と考慮する必要があるから絶対やりたくない

まあそこまでして頑張るのもコストがかかる上に、今後同じコードを使う場合のことも考えると作り直すべき。
すでに作られているソフトをWPFにリファクタ、もしくは一部機能を移植して使ったりするとだいたい起きてしまう。

代々継ぎ足されてきた秘伝のソースはWPFを継ぎ足すと腐るのでやめておきましょうということです。

まとめ

とにかくWPFとWindowsFormsHostの共存は基本的にしないようにしましょう。
どうしても使いたい場合絶対にScrollViewerのようなクリッピング表示をするViewに入れないこと。
そうでなければゴリ押しコードを書く羽目になります。
問題が起きる場合はUIの仕様を考え直すほうがコストは抑えられるはず。

おまけ

WindowsFormsHostを使用したときの描画問題

• http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2644120-bring-back-the-hwndhost-isredirected-and-compositi

• 要約

  • 投稿者: 4.5のプレビュー版で入ってた表示問題の機能が消されたけどどうして？
    あれがあったらみんなハッピーになれるんだけど入れてくれないの？
  • VSチーム: 残念ながらこの機能は追加しません(きっぱり)

この投稿も2012年の話なのでもう諦めるしかないようです。