背景: 由緒ある Sasami2k にインスパイアされた UI を備えた小さなビデオ再生アプリがあり、VMR9 (DirectShow を使用した Direct3D9) を使用するように更新され、不安定になりません。現在、必要に応じて生の Win32 を使用する C++ アプリになっています。特に WPF は、空域の制限により不可能でした。
さて、D3DImage が存在するようになったので、D3D/VMR9/DirectShow と WPF を組み合わせて使用できる可能性があります。Win32 の非拡張性に対する過去のフラストレーションを考えると、これは良いことのように思えます。
でもほら、ここで最初のハードルに落ちています。
Win32 を使用して、サイズ変更可能で比例的にサイズ変更され、画面の端にスナップし、最大化すると画面全体 (タスクバー領域を含む) を占めるボーダレス ウィンドウを (非常に簡単に) 作成しました。これは動画アプリなので、これらはすべて非常に望ましいプロパティです。
では、WPF で同じことを行うにはどうすればよいでしょうか。
Win32 では、次を使用します。 WM_GETMINMAXINFO を使用して最大化動作を制御します WM_NCHITTEST 境界のサイズ変更を制御します
ただし、ドキュメントを誤解していない限り、WPF を見ると、さまざまなイベントの到着が遅すぎるようです。
たとえば、LocationChanged は、ウィンドウが移動したときにのみ起動すると言うため (これは遅すぎます)、いつ移動しているのかわかりません。同様に、StateChanged は、ウィンドウが復元/最大化された後にのみ発生するようです (システムに正しい最大化サイズを伝えるために、最大化の前に情報が必要な場合)。
そして、システムがサイズ変更について教えてくれるところを完全に見落としているようです。ヒットテストも同様です。
それで、ええと、ここで何かが足りないのでしょうか、それとも、とにかくこのことの wndproc をフックすることに戻るしかありませんか? WndProc をフックせずにやりたいことができますか?
WndProc を使用する必要がある場合は、既存のコードベースに固執することもできます。よりシンプルでクリーンな UI コードが必要であり、WndProc から離れることはその基本です。
WndProc をフックする必要がある場合は、疑問に思う必要があります-なぜですか? Win32 には、sizing/sized、moving/moved、poschanged/poschanged ウィンドウ メッセージがあり、それらはすべて役に立ちます。WPF が同じ一連のイベントをレプリケートしないのはなぜですか? 機能の不必要なギャップのようです。
さらに、WPF が特定の USER32 依存の実装に関連付けられていることを意味します。これは、MS が (たとえば Windows 7 または 8 で) 表示レイヤーを反転して WPF を「ネイティブ」にし、レガシ アプリの HWND と WndProcs をエミュレートできないことを意味します。