WPF と Win32 の相互運用性WPF and Win32 Interoperation

このトピックでは、WPFWPF および Win32Win32 コードを相互運用する方法の概要について説明します。This topic provides an overview of how to interoperate WPFWPF and Win32Win32 code. Windows Presentation Foundation (WPF)Windows Presentation Foundation (WPF) は、アプリケーションの作成に適した環境を提供します。 provides a rich environment for creating applications. ただし、Win32Win32 コードに多くの投資を行った場合は、そのコードの一部を再利用する方がより効率的である場合があります。However, when you have a substantial investment in Win32Win32 code, it might be more effective to reuse some of that code.

WPF と Win32 の相互運用の基本WPF and Win32 Interoperation Basics

WPFWPFWin32Win32 コードを相互運用するための基本的な手法は 2 つあります。There are two basic techniques for interoperation between WPFWPF and Win32Win32 code.

  • Win32Win32 ウィンドウで WPFWPF コンテンツをホストします。Host WPFWPF content in a Win32Win32 window. この手法では、標準の WPFWPF ウィンドウおよびアプリケーションのフレームワーク内で Win32Win32 の高度なグラフィックス機能を使用できます。With this technique, you can use the advanced graphics capabilities of WPFWPF within the framework of a standard Win32Win32 window and application.

  • WPFWPF コンテンツで Win32Win32 ウィンドウをホストします。Host a Win32Win32 window in WPFWPF content. この手法では、既存のカスタム Win32Win32 コントロールを他の WPFWPF コンテンツのコンテキストで使用し、境界を越えてデータを渡すことができます。With this technique, you can use an existing custom Win32Win32 control in the context of other WPFWPF content, and pass data across the boundaries.

ここでは、これらの各手法について概念的に説明します。Each of these techniques is conceptually introduced in this topic. Win32Win32WPFWPF をホストする場合のコードを使用した説明については、「チュートリアル: Win32 での WPF コンテンツのホスト」を参照してください。For a more code-oriented illustration of hosting WPFWPF in Win32Win32, see Walkthrough: Hosting WPF Content in Win32. WPFWPFWin32Win32 をホストする場合のコードを使用した説明については、「チュートリアル: WPF での Win32 コントロールのホスト」を参照してください。For a more code-oriented illustration of hosting Win32Win32 in WPFWPF, see Walkthrough: Hosting a Win32 Control in WPF.

WPF 相互運用プロジェクトWPF Interoperation Projects

WPFWPFAPIAPIs はマネージド コードですが、ほとんどの既存の Win32Win32 プログラムはアンマネージド C++C++ で記述されています。 APIAPIs are managed code, but most existing Win32Win32 programs are written in unmanaged C++C++. 純粋なアンマネージ プログラムから WPFWPFAPIAPIs を呼び出すことはできません。You cannot call WPFWPF APIAPIs from a true unmanaged program. ただし、Microsoft Visual C++Microsoft Visual C++ コンパイラで /clr オプションを使用すると、マネージドとアンマネージドの APIAPI 呼び出しをシームレスに混在させることができる、マネージドとアンマネージドの混在プログラムを作成することができます。However, by using the /clr option with the Microsoft Visual C++Microsoft Visual C++ compiler, you can create a mixed managed-unmanaged program where you can seamlessly mix managed and unmanaged APIAPI calls.

プロジェクト レベルで、Extensible Application Markup Language (XAML)Extensible Application Markup Language (XAML) ファイルを C++C++ プロジェクトにコンパイルできないという問題があります。One project-level complication is that you cannot compile Extensible Application Markup Language (XAML)Extensible Application Markup Language (XAML) files into a C++C++ project. これを解決するために、プロジェクトを分割する手法がいくつかあります。There are several project division techniques to compensate for this.

  • すべてを含む c# DLL を作成、XAMLXAMLコンパイル済みのアセンブリとしてページし、C++C++実行可能ファイルが含まれている[DLL]DLL参照として。Create a C# DLL that contains all your XAMLXAML pages as a compiled assembly, and then have your C++C++ executable include that [DLL]DLL as a reference.

  • 作成する c# の実行可能ファイル、WPFWPFし、コンテンツ、参照、 C++C++ [DLL]DLLを格納している、Win32Win32コンテンツ。Create a C# executable for the WPFWPF content, and have it reference a C++C++ [DLL]DLL that contains the Win32Win32 content.

  • 使用LoadをロードXAMLXAMLコンパイルではなく、実行時に、XAMLXAMLします。Use Load to load any XAMLXAML at run time, instead of compiling your XAMLXAML.

  • XAMLXAML を使用せずに、すべての WPFWPF をコードで記述し、Application から要素ツリーを構築します。Do not use XAMLXAML at all, and write all your WPFWPF in code, building up the element tree from Application.

これらの中で最適な方法を使用してください。Use whatever approach works best for you.

注意

C++/CLIC++/CLI を使用したことがない場合は、相互運用のコード例に gcnewnullptr などの "見慣れない" キーワードがあるかもしれません。If you have not used C++/CLIC++/CLI before, you might notice some "new" keywords such as gcnew and nullptr in the interoperation code examples. 古い二重アンダースコアの構文 (__gc) がこれらのキーワードによって置き換えられています。これらのキーワードを使用すると、C++C++ のマネージド コードの構文がより自然になります。These keywords supersede the older double-underscore syntax (__gc) and provide a more natural syntax for managed code in C++C++. C++/CLIC++/CLI マネージド機能の詳細については、「ランタイム プラットフォームのコンポーネントの拡張機能」および「Hello, C++/CLI」(C++/CLI 入門) を参照してください。To learn more about the C++/CLIC++/CLI managed features, see Component Extensions for Runtime Platforms and Hello, C++/CLI.

WPF での Hwnd の使用方法How WPF Uses Hwnds

ほとんどの WPFWPF "HWND 相互運用" を行うには、WPFWPF での HWND の使用方法を理解する必要があります。To make the most of WPFWPF "HWND interop", you need to understand how WPFWPF uses HWNDs. HWND では、WPFWPF レンダリングを DirectXDirectX レンダリングまたは GDIGDI / GDI+GDI+ レンダリングと混在させることはできません。For any HWND, you cannot mix WPFWPF rendering with DirectXDirectX rendering or GDIGDI / GDI+GDI+ rendering. 混在させると、さまざまな影響が生じます。This has a number of implications. 主に、これらのレンダリング モデルを混在させるには、相互運用ソリューションを作成し、使用するレンダリング モデルごとに指定された相互運用セグメントを使用する必要があります。Primarily, in order to mix these rendering models at all, you must create an interoperation solution, and use designated segments of interoperation for each rendering model that you choose to use. また、相互運用ソリューションで実現できる動作に対する "空域" 制限がレンダリング動作によって生じます。Also, the rendering behavior creates an "airspace" restriction for what your interoperation solution can accomplish. "空域" の概念の詳細については、「技術領域の概要」のトピックを参照してください。The "airspace" concept is explained in greater detail in the topic Technology Regions Overview.

画面上のすべての WPFWPF 要素は最終的に HWND によってサポートされます。All WPFWPF elements on the screen are ultimately backed by a HWND. 作成するときに、 WPFWPF WindowWPFWPFトップレベルの HWND を作成して使用して、HwndSourceを配置する、WindowとそのWPFWPFコンテンツが HWND 内。When you create a WPFWPF Window, WPFWPF creates a top-level HWND, and uses an HwndSource to put the Window and its WPFWPF content inside the HWND. アプリケーション内の残りの WPFWPF コンテンツは、その単一の HWND を共有します。The rest of your WPFWPF content in the application shares that singular HWND. ただし、メニュー、コンボ ボックス ドロップダウン、およびその他のポップアップは例外です。An exception is menus, combo box drop downs, and other pop-ups. これらの要素では独自のトップレベル ウィンドウが作成されます。このため WPFWPF メニューは、そのメニューを格納するウィンドウ HWND の端を越える可能性があります。These elements create their own top-level window, which is why a WPFWPF menu can potentially go past the edge of the window HWND that contains it. 使用するとHwndHost内で HWND を配置するWPFWPFWPFWPF通知Win32Win32に新しい子 hwnd を配置する方法、 WPFWPF Window HWND。When you use HwndHost to put an HWND inside WPFWPF, WPFWPF informs Win32Win32 how to position the new child HWND relative to the WPFWPF Window HWND.

HWND の関連概念として、各 HWND 内および各 HWND 間の透過性が挙げられます。A related concept to HWND is transparency within and between each HWND. これについても「技術領域の概要」のトピックで解説されています。This is also discussed in the topic Technology Regions Overview.

Microsoft Win32 ウィンドウでの WPF コンテンツのホストHosting WPF Content in a Microsoft Win32 Window

WPFWPF ウィンドウで Win32Win32 をホストするキーとなるのは、HwndSource クラスです。The key to hosting a WPFWPF on a Win32Win32 window is the HwndSource class. このクラスは WPFWPF ウィンドウの Win32Win32 コンテンツをラップし、その WPFWPF コンテンツを子ウィンドウとしてユーザー インターフェイス (UI)user interface (UI) に組み込むことができます。This class wraps the WPFWPF content in a Win32Win32 window, so that the WPFWPF content can be incorporated into your ユーザー インターフェイス (UI)user interface (UI) as a child window. 次の方法では、Win32Win32 および WPFWPF を単一のアプリケーションに統合します。The following approach combines the Win32Win32 and WPFWPF in a single application.

  1. WPFWPF コンテンツ (コンテンツのルート要素) をマネージド クラスとして実装します。Implement your WPFWPF content (the content root element) as a managed class. 通常、このクラスは、複数の子要素を格納できるクラスやルート要素として使用されるクラスのいずれか (DockPanelPage など) から継承されます。Typically, the class inherits from one of the classes that can contain multiple child elements and/or used as a root element, such as DockPanel or Page. 以降の手順では、このクラスを WPFWPF コンテンツ クラスと呼び、そのクラスのインスタンスを WPFWPF コンテンツ オブジェクトと呼びます。In subsequent steps, this class is referred to as the WPFWPF content class, and instances of the class are referred to as WPFWPF content objects.

  2. Win32Win32 アプリケーションを C++/CLIC++/CLI で実装します。Implement a Win32Win32 application with C++/CLIC++/CLI. 既存のアンマネージド C++C++ アプリケーションから始める場合、通常、/clr コンパイラ フラグが含まれるようにプロジェクトの設定を変更して、アプリケーションでマネージド コードを呼び出すようにできます (/clr コンパイルをサポートするための要件の詳細については、ここでは説明しません)。If you are starting with an existing unmanaged C++C++ application, you can usually enable it to call managed code by changing your project settings to include the /clr compiler flag (the full scope of what might be necessary to support /clr compilation is not described in this topic).

  3. スレッド処理モデルをシングル スレッド アパートメント (STA: Single Threaded Apartment) に設定します。Set the threading model to Single Threaded Apartment (STA). このスレッド処理モデルを使用するのは WPFWPF のみです。WPFWPF uses this threading model.

  4. ウィンドウ プロシージャで WM_CREATE 通知を処理します。Handle the WM_CREATE notification in your window procedure.

  5. ハンドラー (またはハンドラーが呼び出す関数) で、次の手順を実行します。Within the handler (or a function that the handler calls), do the following:

    1. HwndSource パラメーターとして親ウィンドウ HWND を持つ新しい parent オブジェクトを作成します。Create a new HwndSource object with the parent window HWND as its parent parameter.

    2. WPFWPF コンテンツ クラスのインスタンスを作成します。Create an instance of your WPFWPF content class.

    3. 参照を割り当てる、WPFWPFコンテンツ オブジェクト、HwndSourceオブジェクトRootVisualプロパティ。Assign a reference to the WPFWPF content object to the HwndSource object RootVisual property.

    4. HwndSource オブジェクトの Handle プロパティにウィンドウ ハンドル (HWND) が格納されます。The HwndSource object Handle property contains the window handle (HWND). アプリケーションのアンマネージ部分で使用できる HWND を取得するには、Handle.ToPointer() を HWND にキャストします。To get an HWND that you can use in the unmanaged part of your application, cast Handle.ToPointer() to an HWND.

  6. WPFWPF コンテンツ オブジェクトへの参照を保持する静的フィールドを含むマネージド クラスを実装します。Implement a managed class that contains a static field that holds a reference to your WPFWPF content object. このクラスへの参照を取得することができます、WPFWPFコンテンツ オブジェクトから、Win32Win32コードも防ぐことが重要なは、HwndSourceが不注意によってガベージ コレクションします。This class allows you to get a reference to the WPFWPF content object from your Win32Win32 code, but more importantly it prevents your HwndSource from being inadvertently garbage collected.

  7. ハンドラーを 1 つ以上の WPFWPF コンテンツ オブジェクト イベントにアタッチして、WPFWPF コンテンツ オブジェクトから通知を受信します。Receive notifications from the WPFWPF content object by attaching a handler to one or more of the WPFWPF content object events.

  8. 静的フィールドに格納した参照を使用してプロパティの設定やメソッドの呼び出しなどを行い、WPFWPF コンテンツ オブジェクトと通信します。Communicate with the WPFWPF content object by using the reference that you stored in the static field to set properties, call methods, etc.

注意

個別のアセンブリを生成して参照する場合は、手順 1 の WPFWPF コンテンツ クラスの一部またはすべてについて、XAMLXAML でコンテンツ クラスの既定の部分クラスを使用して定義できます。You can do some or all of the WPFWPF content class definition for Step One in XAMLXAML using the default partial class of the content class, if you produce a separate assembly and then reference it. 通常は、Application オブジェクトを XAMLXAML のコンパイルの一部としてアセンブリに含めますが、その Application を相互運用の一部として使用することにはなりません。単に、アプリケーションによって参照される XAMLXAML ファイルの 1 つ以上のルート クラスを使用し、その部分クラスを参照します。Although you typically include an Application object as part of compiling the XAMLXAML into an assembly, you do not end up using that Application as part of the interoperation, you just use one or more of the root classes for XAMLXAML files referred to by the application and reference their partial classes. 手順の残りの部分は、基本的に前述の手順と同様です。The remainder of the procedure is essentially similar to that outlined above.

これらの各手順のコードを使用した説明については、「チュートリアル: Win32 での WPF コンテンツのホスト」のトピックを参照してください。Each of these steps is illustrated through code in the topic Walkthrough: Hosting WPF Content in Win32.

WPF での Microsoft Win32 ウィンドウのホストHosting a Microsoft Win32 Window in WPF

ホストする鍵をWin32Win32内でその他のウィンドウWPFWPFコンテンツは、HwndHostクラス。The key to hosting a Win32Win32 window within other WPFWPF content is the HwndHost class. このクラスは、WPFWPF 要素ツリーに追加できる WPFWPF 要素でウィンドウをラップします。This class wraps the window in a WPFWPF element which can be added to a WPFWPF element tree. HwndHost ではAPIAPIsホストされたウィンドウのメッセージ処理としてこのようなタスクを実行することができます。HwndHost also supports APIAPIs that allow you to do such tasks as process messages for the hosted window. 基本手順は次のとおりです。The basic procedure is:

  1. WPFWPF アプリケーションの要素ツリーを作成します (コードまたはマークアップによって)。Create an element tree for a WPFWPF application (can be through code or markup). HwndHost の実装を子要素として追加できる適切な許可ポイントを要素ツリーで検索します。Find an appropriate and permissible point in the element tree where the HwndHost implementation can be added as a child element. この手順では以後、この要素を予約要素と呼びます。In the remainder of these steps, this element is referred to as the reserving element.

  2. HwndHost からの派生クラスを作成し、Win32Win32 コンテンツを保持するオブジェクトを作成します。Derive from HwndHost to create an object that holds your Win32Win32 content.

  3. そのホスト クラスで、HwndHostBuildWindowCore メソッドをオーバーライドします。In that host class, override the HwndHost method BuildWindowCore. ホストされたウィンドウの HWND を返します。Return the HWND of the hosted window. 返されたウィンドウの子ウィンドウとして実際のコントロールをラップすることもできます。ホスト ウィンドウでコントロールをラップすると、WPFWPF コンテンツでコントロールからの通知を簡単に受信できます。You might want to wrap the actual control(s) as a child window of the returned window; wrapping the controls in a host window provides a simple way for your WPFWPF content to receive notifications from the controls. この手法により、ホストされたコントロールの境界でのメッセージ処理に関するいくつかの Win32Win32 問題を修正できます。This technique helps correct for some Win32Win32 issues regarding message handling at the hosted control boundary.

  4. HwndHostDestroyWindowCore メソッドと WndProc メソッドをオーバーライドします。Override the HwndHost methods DestroyWindowCore and WndProc. これは、クリーンアップの処理およびホストされたコンテンツへの参照の削除を行うためです (特に、アンマネージ オブジェクトへの参照を作成した場合)。The intention here is to process cleanup and remove references to the hosted content, particularly if you created references to unmanaged objects.

  5. 分離コード ファイルで、コントロール ホスト クラスのインスタンスを作成し、予約要素の子にします。In your code-behind file, create an instance of the control hosting class and make it a child of the reserving element. 通常は、Loaded などのイベント ハンドラーを使用するか、部分クラス コンストラクターを使用します。Typically you would use an event handler such as Loaded, or use the partial class constructor. ただし、ランタイム動作によって相互運用コンテンツを追加することもできます。But you could also add the interoperation content through a runtime behavior.

  6. コントロールの通知などの選択されたウィンドウ メッセージを処理します。Process selected window messages, such as control notifications. 処理方法は 2 つあります。There are two approaches. どちらも同様にメッセージ ストリームにアクセスできるようにするため、どちらを選択するかは、多くの場合、プログラミングの便宜上の理由によって決まります。Both provide identical access to the message stream, so your choice is largely a matter of programming convenience.

    • HwndHostWndProc メソッドのオーバーライドで、シャットダウン メッセージだけでなくすべてのメッセージのメッセージ処理を実装します。Implement message processing for all messages (not just shutdown messages) in your override of the HwndHost method WndProc.

    • WPFWPF イベントを処理して、ホスト MessageHook 要素でメッセージを処理します。Have the hosting WPFWPF element process the messages by handling the MessageHook event. このイベントは、ホストされたウィンドウのメイン ウィンドウ プロシージャに送信されるすべてのメッセージに対して発生します。This event is raised for every message that is sent to the main window procedure of the hosted window.

    • メッセージは、WndProc を使用するプロセスで発生したウィンドウからは処理できません。You cannot process messages from windows that are out of process using WndProc.

  7. プラットフォーム呼び出しを使用してアンマネージ SendMessage 関数を呼び出し、ホストされたウィンドウと通信します。Communicate with the hosted window by using platform invoke to call the unmanaged SendMessage function.

次の手順に従って、マウス入力で動作するアプリケーションを作成します。Following these steps creates an application that works with mouse input. IKeyboardInputSink インターフェイスを実装して、ホストされたウィンドウで Tab キーによる移動がサポートされるようにすることができます。You can add tabbing support for your hosted window by implementing the IKeyboardInputSink interface.

これらの各手順のコードを使用した説明については、「チュートリアル: WPF での Win32 コントロールのホスト」のトピックを参照してください。Each of these steps is illustrated through code in the topic Walkthrough: Hosting a Win32 Control in WPF.

WPF 内の HWNDHwnds Inside WPF

HwndHost は特殊なコントロールであると考えることができます You can think of HwndHost as a special control. (技術的には、HwndHostは、FrameworkElement派生クラスではない、Control派生クラスでは、相互運用のためのコントロールを考慮することができます)。HwndHost 、基になる抽象化Win32Win32ホストされたコンテンツの性質の残りの部分WPFWPFホストされているコンテンツをレンダリングし、入力を処理する必要がありますが、別のコントロールのようなオブジェクトと見なします。(Technically, HwndHost is a FrameworkElement derived class, not a Control derived class, but it can be considered a control for purposes of interoperation.) HwndHost abstracts the underlying Win32Win32 nature of the hosted content such that the remainder of WPFWPF considers the hosted content to be another control-like object, which should render and process input. HwndHost 一般に、他のように動作WPFWPFFrameworkElement出力 (描画とグラフィックス) いくつか重要な違いがあるし、どのような基になる Hwnd の制限事項に基づく入力 (マウスとキーボード) をサポートできます。HwndHost generally behaves like any other WPFWPF FrameworkElement, although there are some important differences around output (drawing and graphics) and input (mouse and keyboard) based on limitations of what the underlying HWNDs can support.

出力動作の顕著な違いNotable Differences in Output Behavior

  • FrameworkElement の基底クラスである HwndHost には、UI の変更に関係する多くのプロパティが用意されています。FrameworkElement, which is the HwndHost base class, has quite a few properties that imply changes to the UI. これには、親要素内の要素のレイアウトを変更する FrameworkElement.FlowDirection などのプロパティが含まれます。These include properties such as FrameworkElement.FlowDirection, which changes the layout of elements within that element as a parent. ただし、これらのプロパティの多くは、Win32Win32 で等価機能が存在し得るとしても、それに対応付けられていません。However, most of these properties are not mapped to possible Win32Win32 equivalents, even if such equivalents might exist. 非常に多くのプロパティとその意味がレンダリング テクノロジ固有でありすぎるために、対応付けをしても役に立ちません。Too many of these properties and their meanings are too rendering-technology specific for mappings to be practical. そのためなどのプロパティを設定FlowDirectionHwndHostも何も起こりません。Therefore, setting properties such as FlowDirection on HwndHost has no effect.

  • HwndHost は、回転、拡大縮小、傾斜、または変換の影響を受けません。HwndHost cannot be rotated, scaled, skewed, or otherwise affected by a Transform.

  • HwndHost では、Opacity プロパティ (アルファ ブレンディング) はサポートされません。HwndHost does not support the Opacity property (alpha blending). HwndHost 内のコンテンツでアルファ情報を含む System.Drawing 操作が実行される場合、それ自体は違反ではありませんが、HwndHost 全体では不透明度 = 1.0 (100%) のみがサポートされます。If content inside the HwndHost performs System.Drawing operations that include alpha information, that is itself not a violation, but the HwndHost as a whole only supports Opacity = 1.0 (100%).

  • HwndHost は、同じトップレベル ウィンドウの他の WPFWPF 要素の上に表示されます。HwndHost will appear on top of other WPFWPF elements in the same top-level window. ただし、ToolTip または ContextMenu で生成されるメニューは独立したトップレベル ウィンドウであるため、HwndHost で正しく動作します。However, a ToolTip or ContextMenu generated menu is a separate top-level window, and so will behave correctly with HwndHost.

  • HwndHost は、親 UIElement のクリッピング領域に対応しません。HwndHost does not respect the clipping region of its parent UIElement. これは、HwndHost クラスをスクロール領域または Canvas に格納しようとする場合に問題となる可能性があります。This is potentially an issue if you attempt to put an HwndHost class inside a scrolling region or Canvas.

入力動作の顕著な違いNotable Differences in Input Behavior

  • 通常、入力デバイスは、HwndHost がホストする Win32Win32 領域内がスコープとなり、入力イベントは Win32Win32 に直接移動します。In general, while input devices are scoped within the HwndHost hosted Win32Win32 region, input events go directly to Win32Win32.

  • 上にマウスが中に、 HwndHost、アプリケーションが受信しませんWPFWPFマウス イベントを受け取らず、値のWPFWPFプロパティIsMouseOverなりますfalseします。While the mouse is over the HwndHost, your application does not receive WPFWPF mouse events, and the value of the WPFWPF property IsMouseOver will be false.

  • 中に、HwndHostキーボード フォーカスがある、アプリケーションは受け取りませんWPFWPFキーボード イベントの値、WPFWPFプロパティIsKeyboardFocusWithinなりますfalseします。While the HwndHost has keyboard focus, your application will not receive WPFWPF keyboard events and the value of the WPFWPF property IsKeyboardFocusWithin will be false.

  • 内でフォーカスがある場合、HwndHost内の別のコントロールが変更され、 HwndHost、アプリケーションは受信しません、WPFWPFイベントGotFocusまたはLostFocusします。When focus is within the HwndHost and changes to another control inside the HwndHost, your application will not receive the WPFWPF events GotFocus or LostFocus.

  • 関連するスタイラス プロパティおよびイベントは類似しており、スタイラスが HwndHost 上にあるときは情報を報告しません。Related stylus properties and events are analogous, and do not report information while the stylus is over HwndHost.

Tab キーによる移動、ニーモニック、およびアクセラレータTabbing, Mnemonics, and Accelerators

IKeyboardInputSink インターフェイスおよび IKeyboardInputSite インターフェイスを使用すると、WPFWPFWin32Win32 が混在するアプリケーションでシームレスなキーボード操作を実現できます。The IKeyboardInputSink and IKeyboardInputSite interfaces allow you to create a seamless keyboard experience for mixed WPFWPF and Win32Win32 applications:

  • Win32Win32 コンポーネントと WPFWPF コンポーネント間の Tab キーによる移動Tabbing between Win32Win32 and WPFWPF components

  • フォーカスが Win32 コンポーネント内にある場合と WPF コンポーネント内にある場合の両方で動作するニーモニックおよびアクセラレータMnemonics and accelerators that work both when focus is within a Win32 component and when it is within a WPF component.

HwndHost クラスと HwndSource クラスはどちらも IKeyboardInputSink の実装を提供しますが、より高度なシナリオで必要な入力メッセージが一部処理されない場合があります。The HwndHost and HwndSource classes both provide implementations of IKeyboardInputSink, but they may not handle all the input messages that you want for more advanced scenarios. 適切なメソッドをオーバーライドして、必要なキーボード動作を確保してください。Override the appropriate methods to get the keyboard behavior you want.

インターフェイスは、WPFWPF 領域と Win32Win32 領域間の遷移で発生する処理をサポートするだけです。The interfaces only provide support for what happens on the transition between the WPFWPF and Win32Win32 regions. Win32Win32 領域では、Tab キーによる移動動作は、Tab キーによる移動の Win32Win32 実装ロジック (ある場合) によって完全に制御されます。Within the Win32Win32 region, tabbing behavior is entirely controlled by the Win32Win32 implemented logic for tabbing, if any.

関連項目See Also

HwndHost
HwndSource
System.Windows.Interop
チュートリアル: WPF での Win32 コントロールのホストWalkthrough: Hosting a Win32 Control in WPF
チュートリアル: Win32 での WPF コンテンツのホストWalkthrough: Hosting WPF Content in Win32