WPF と Windows フォームの相互運用性
WPF と Windows フォームでは、アプリケーション インターフェイスを作成するための 2 つの異なるアーキテクチャが提供されます。 System.Windows.Forms.Integration 名前空間では、一般的な相互運用シナリオを可能にするクラスが提供されています。 相互運用機能を実装する 2 つの主要なクラスは、WindowsFormsHost と ElementHost です。 このトピックでは、サポートされている相互運用シナリオとサポートされていないシナリオについて説明します。
注意
"ハイブリッド コントロール" のシナリオについては、特別な考慮事項があります。 ハイブリッド コントロールでは、あるテクノロジのコントロールが他のテクノロジのコントロールに入れ子になっています。 これは、"入れ子になった相互運用" とも呼ばれます。 "マルチレベル ハイブリッド コントロール" では、複数のレベルのハイブリッド コントロールが入れ子になっています。 マルチレベルの入れ子になった相互運用の一例は、Windows フォーム コントロールに WPF コントロールが含まれており、その WPF コントロールには別の Windows フォーム コントロールが含まれている場合です。 マルチレベル ハイブリッド コントロールはサポートされていません。
WPF での Windows フォーム コントロールのホスティング
WPF コントロールで Windows フォーム コントロールがホストされている場合、次の相互運用シナリオがサポートされます。
WPF コントロールでは、XAML を使用して 1 つ以上の Windows フォーム コントロールをホストできます。
コード を使用して 1 つ以上の Windows フォーム コントロールをホストできます。
他の Windows フォーム コントロールが含まれる Windows フォーム コンテナー コントロールをホストできます。
WPF をマスター、Windows フォームを詳細にして、マスターと詳細のフォームをホストできます。
Windows フォームをマスター、WPF を詳細にして、マスターと詳細のフォームをホストできます。
1 つ以上の ActiveX コントロールをホストできます。
1 つ以上の複合コントロールをホストできます。
Extensible Application Markup Language (XAML) を使用してハイブリッド コントロールをホストできます。
コードを使用してハイブリッド コントロールをホストできます。
レイアウトのサポート
次の一覧は、WindowsFormsHost 要素を使用して、ホストされている Windows フォーム コントロールを WPF レイアウト システムに統合する際の既知の制限事項について説明しています。
場合によっては、Windows フォーム コントロールのサイズを変更できません。または、特定のサイズにしか限定できません。 たとえば、Windows フォームの ComboBox コントロールでは、コントロールのフォント サイズによって定義される 1 つの高さのみがサポートされます。 WPF の動的レイアウトでは、要素を垂直方向に伸縮できるものと想定されていますが、ホストされている ComboBox コントロールは想定したとおりに伸縮されません。
Windows フォーム コントロールを回転または傾斜させることはできません。 たとえば、ユーザー インターフェイスを 90 度回転させても、ホストされている Windows フォーム コントロールは縦向きのままになります。
ほとんどの場合、Windows フォーム コントロールでは比率を維持したスケーリングはサポートされていません。 コントロール全体の寸法はスケーリングされますが、コントロールの子コントロールとコンポーネント要素は、想定したとおりにサイズ変更されない可能性があります。 この制限は、各 Windows フォーム コントロールでスケーリングがどの程度サポートされているかによって異なります。
WPF のユーザー インターフェイスでは、要素の Z オーダー を変更して、重なり具合を制御できます。 ホストされている Windows フォーム コントロールは別の HWND で描画されるため、常に WPF 要素の上に描画されます。
Windows フォーム コントロールでは、フォント サイズに基づく自動スケーリングがサポートされています。 WPF のユーザー インターフェイスでは、フォント サイズを変更すると、個々の要素のサイズが動的に変更されても、レイアウト全体のサイズが変更されることはありません。
アンビエント プロパティ
WPF コントロールの一部のアンビエント プロパティには、Windows フォームにそれに対応するものがあります。 これらのアンビエント プロパティは、ホストされている Windows フォーム コントロールに反映され、WindowsFormsHost コントロールのパブリック プロパティとして公開されます。 WindowsFormsHost では、WPF の各アンビエント プロパティが Windows フォームのそれに対応するプロパティに変換されます。
詳細については、「Windows フォームと WPF のプロパティ マッピング」を参照してください。
動作
次の表では、相互運用動作について説明します。
| 動作 | サポート状況 | サポートなし |
|---|---|---|
| [透明度] | Windows フォーム コントロールのレンダリングでは、透明度がサポートされています。 親の WPF コントロールの背景を、ホストされている Windows フォーム コントロールの背景にすることができます。 | 一部の Windows フォーム コントロールでは、透明度がサポートされていません。 たとえば、TextBox コントロールや ComboBox コントロールは、WPF でホストされている場合、透明になりません。 |
| タブ移動 | ホストされている Windows フォーム コントロールのタブ オーダーは、それらのコントロールが Windows フォーム ベースのアプリケーションでホストされている場合と同じです。 Tab キーおよび Shift + Tab キーを使用する Tab キーでの WPF コントロールから Windows フォーム コントロールへの移動は、通常どおりに動作します。 TabStop プロパティの値が false である Windows フォーム コントロールは、ユーザーがコントロールをタブ移動したときにフォーカスを受け取りません。- 各 WindowsFormsHost コントロールには TabIndex 値があり、それによって WindowsFormsHost コントロールがいつフォーカスを受け取るかが決定されます。 - WindowsFormsHost コンテナー内に含まれる Windows フォーム コントロールは、TabIndex プロパティによって指定されている順序に従います。 最後のタブ インデックスから Tab キーで移動すると、次の WPF コントロールが存在する場合、それにフォーカスが移動します。 フォーカスできる WPF コントロールが他に存在しない場合は、Tab キーでの移動により、タブ オーダーで先頭の Windows フォーム コントロールに戻ります。 - WindowsFormsHost の内部にあるコントロールの TabIndex の値は、WindowsFormsHost コントロールに含まれる兄弟 Windows フォーム コントロールに対して相対的です。 - Tab キーでの移動では、コントロール固有の動作が優先されます。 たとえば、AcceptsTab プロパティの値が true である TextBox コントロールで Tab キーを押すと、フォーカスが移動するのではなく、テキスト ボックス内にタブが入ります。 |
該当なし。 |
| 方向キーによるナビゲーション | - WindowsFormsHost コントロールでの方向キーによる移動は、通常の Windows フォーム コンテナー コントロールと同じです。つまり、上方向キーと左方向キーでは前のコントロールが選択され、下方向キーと右方向キーでは次のコントロールが選択されます。 - WindowsFormsHost コントロールに含まれる最初のコントロールで上方向キーまたは左方向キーを押すと、Shift + Tab キーボード ショートカットと同じ操作が実行されます。 フォーカスできる WindowsFormsHost コントロールがある場合、フォーカスは WPF コントロールの外に移動します。 この動作は、最後のコントロールへのラップが行われないという点で、ContainerControl の標準動作とは異なります。 フォーカスできる WPF コントロールが他に存在しない場合、フォーカスは、タブ オーダーで最後の Windows フォーム コントロールに戻ります。 - WindowsFormsHost コントロールに含まれる最後のコントロールで下方向キーまたは右方向キーを押すと、Tab キーと同じ操作が実行されます。 フォーカスできる WindowsFormsHost コントロールがある場合、フォーカスは WPF コントロールの外に移動します。 この動作は、最初のコントロールへのラップが行われないという点で、ContainerControl の標準動作とは異なります。 フォーカスできる WPF コントロールが他に存在しない場合、フォーカスは、タブ オーダーで最初の Windows フォーム コントロールに戻ります。 |
該当なし。 |
| アクセラレータ | アクセラレータは、"サポートされていない" 列に記載されていることを除き、通常どおりに動作します。 | テクノロジをまたぐ重複するアクセラレータは、通常の重複するアクセラレータと同じようには機能しません。 複数のテクノロジ間でアクセラレータが重複すると (少なくとも 1 つが Windows フォーム コントロール上にあり、他が WPF コントロール上にある場合)、Windows フォーム コントロールが常にアクセラレータを受け取ります。 重複するアクセラレータが押された場合、コントロールの間でフォーカスが切り替えられることはありません。 |
| ショートカット キー | ショートカット キーは、"サポートされていない" 列に記載されていることを除き、通常どおりに動作します。 | - 前処理段階で処理される Windows フォームのショートカット キーは、WPF のショートカット キーより常に優先されます。 たとえば、Ctrl + S ショートカット キーが定義されている ToolStrip コントロールがあり、Ctrl + S にバインドされた WPF コマンドがある場合、フォーカスに関係なく、ToolStrip コントロールのハンドラーが常に最初に呼び出されます。 - KeyDown イベントによって処理される Windows フォームのショートカット キーは、WPF で最後に処理されます。 Windows フォーム コントロールの IsInputKey メソッドをオーバーライドするか、PreviewKeyDown イベントを処理することで、この動作を回避できます。 IsInputKey メソッドから true を返すか、または PreviewKeyDown のイベント ハンドラーで PreviewKeyDownEventArgs.IsInputKey プロパティの値を true に設定します。 |
| AcceptsReturn、AcceptsTab、およびその他のコントロール固有の動作 | Windows フォーム コントロールで IsInputKey メソッドが true を返すようにオーバーライドされていれば、既定のキーボード動作を変更するプロパティは通常どおり動作します。 |
KeyDown イベントを処理することによって既定のキーボード動作を変更する Windows フォーム コントロールは、ホスト WPF コントロールで最後に処理されます。 これらのコントロールは最後に処理されるため、予期しない動作が発生する可能性があります。 |
| Enter イベントと Leave イベント | 外側の ElementHost コントロールにフォーカスが移動しない場合、1 つの WindowsFormsHost コントロール内でフォーカスが変化すると、Enter イベントと Leave イベントが通常どおりに発生します。 | 次のようなフォーカスの変化が発生すると、Enter イベントと Leave イベントは発生しません。 - WindowsFormsHost コントロールの内側から外側へ。 - WindowsFormsHost コントロールの外側から内側へ。 - WindowsFormsHost コントロールの外側。 - WindowsFormsHost コントロールでホストされている Windows フォーム コントロールから、同じ WindowsFormsHost の内側でホストされている ElementHost コントロールへ。 |
| マルチスレッド | マルチスレッドのすべてのバリエーションがサポートされています。 | Windows フォームと WPF のどちらのテクノロジでも、シングルスレッドのコンカレンシー モデルが想定されています。 デバッグ中に、他のスレッドからフレームワーク オブジェクトを呼び出すと、例外が発生し、この要件が適用されます。 |
| セキュリティ | すべての相互運用シナリオでは、完全な信頼が必要です。 | 部分的な信頼では、相互運用シナリオは許可されません。 |
| ユーザー補助 | すべてのアクセシビリティ シナリオがサポートされています。 支援技術製品は、Windows フォームと WPF の両方のコントロールを含むハイブリッド アプリケーションで使用される場合、正しく機能します。 | 該当なし。 |
| クリップボードのトピック | すべてのクリップボード操作は通常どおりに動作します。 これには、Windows フォーム コントロールと WPF コントロールの間での切り取りと貼り付けが含まれます。 | 該当なし。 |
| ドラッグ アンド ドロップ機能 | すべてのドラッグ アンド ドロップ操作は通常どおりに動作します。 これには、Windows フォーム コントロールと WPF コントロールの間での操作が含まれます。 | 該当なし。 |
Windows フォームでの WPF コントロールのホスト
Windows フォーム コントロールで WPF コントロールがホストされている場合、次の相互運用シナリオがサポートされます。
コードを使用した 1 つ以上の WPF コントロールのホスト。
プロパティ シートと 1 つ以上のホストされている WPF コントロールの関連付け。
フォームでの 1 つ以上の WPF ページのホスト。
WPF ウィンドウの開始。
Windows フォームをマスター、WPF を詳細とする、マスターと詳細のフォームのホスト。
WPF をマスター、Windows フォームを詳細とする、マスターと詳細のフォームのホスト。
カスタム WPF コントロールのホスト。
ハイブリッド コントロールのホスト。
アンビエント プロパティ
Windows フォーム コントロールの一部のアンビエント プロパティには、WPF に対応するものがあります。 これらのアンビエント プロパティは、ホストされている WPF コントロールに反映され、ElementHost コントロールのパブリック プロパティとして公開されます。 ElementHost コントロールでは、Windows フォームの各アンビエント プロパティが WPF のそれに対応するプロパティに変換されます。
詳細については、「Windows フォームと WPF のプロパティ マッピング」を参照してください。
動作
次の表では、相互運用動作について説明します。
| 動作 | サポート状況 | サポートなし |
|---|---|---|
| [透明度] | WPF コントロールのレンダリングでは、透明度がサポートされます。 親の Windows フォーム コントロールの背景を、ホストされている WPF コントロールの背景にすることができます。 | 該当なし。 |
| マルチスレッド | マルチスレッドのすべてのバリエーションがサポートされています。 | Windows フォームと WPF のどちらのテクノロジでも、シングルスレッドのコンカレンシー モデルが想定されています。 デバッグ中に、他のスレッドからフレームワーク オブジェクトを呼び出すと、例外が発生し、この要件が適用されます。 |
| セキュリティ | すべての相互運用シナリオでは、完全な信頼が必要です。 | 部分的な信頼では、相互運用シナリオは許可されません。 |
| ユーザー補助 | すべてのアクセシビリティ シナリオがサポートされています。 支援技術製品は、Windows フォームと WPF の両方のコントロールを含むハイブリッド アプリケーションで使用される場合、正しく機能します。 | 該当なし。 |
| クリップボードのトピック | すべてのクリップボード操作は通常どおりに動作します。 これには、Windows フォーム コントロールと WPF コントロールの間での切り取りと貼り付けが含まれます。 | 該当なし。 |
| ドラッグ アンド ドロップ機能 | すべてのドラッグ アンド ドロップ操作は通常どおりに動作します。 これには、Windows フォーム コントロールと WPF コントロールの間での操作が含まれます。 | 該当なし。 |
関連項目
.NET Desktop feedback