UI オートメーション プロバイダーの概要
.gif "メモ") メモ |
|---|
このドキュメントは、System.Windows.Automation 名前空間で定義されているマネージ UI Automation クラスを使用する .NET Framework 開発者を対象としています。UI Automationに関する最新情報については、「Windows Automation API: UI Automation (Windows オートメーション API: UI オートメーション)」を参照してください。 |
UI オートメーション プロバイダーとは、コントロールが UI オートメーション クライアント アプリケーションと通信するためのしくみです。 一般に、user interface (UI) 内のコントロールやその他の独立した要素はそれぞれ、1 つのプロバイダーによって表されます。 プロバイダーによって、その要素についての情報が公開されますが、クライアント アプリケーションがコントロールと対話するためのコントロール パターンを実装することもできます。
通常は、クライアント アプリケーションがプロバイダーを直接操作する必要はありません。 Win32、Windows Forms、または Windows Presentation Foundation (WPF) のフレームワークを使用するアプリケーションの標準コントロールのほとんどは、自動的に UI Automation システムに対して公開されます。 アプリケーションでカスタム コントロールを実装するときも、そのコントロールに対する UI Automation プロバイダーを実装することが可能ですが、アクセスするための特別な手順をクライアント アプリケーション側で用意する必要はありません。
ここでは、コントロール開発者が、特に Windows Formsおよび Win32 のウィンドウ内のコントロールに対して、UI Automation プロバイダーを実装する方法の概要について説明します。
このトピックは、次のセクションで構成されています。
- プロバイダーの種類
- UI オートメーション プロバイダーの概念
- 関連トピック
プロバイダーの種類
UI オートメーション プロバイダーは、クライアント側プロバイダーとサーバー側プロバイダーの 2 つのカテゴリに分かれます。
クライアント側プロバイダー
クライアント側プロバイダーは UI オートメーション クライアントによって実装され、UI Automationをサポートしていないアプリケーション、または完全にはサポートしていないアプリケーションと通信します。 クライアント側プロバイダーとサーバーとがプロセスの境界を越えて通信するには、通常、Windows メッセージが送受信されます。
Win32、Windows Forms、または WPF のアプリケーションのコントロールに対する UI オートメーション プロバイダーは、オペレーティング システムの一部として提供されるため、ほとんどの場合、クライアント アプリケーションは独自のプロバイダーを実装する必要はありません。この概要では、これらについては詳細には説明しません。
サーバー側プロバイダー
サーバー側プロバイダーは、Win32、Windows Forms、または WPF 以外の UI フレームワークに基づくカスタム コントロールまたはアプリケーションによって実装されます。
サーバー側プロバイダーとクライアント アプリケーションとがプロセスの境界を越えて通信するために、インターフェイスが UI Automation コア システム対して公開され、コア システムによってクライアントからの要求が処理されます。
UI オートメーション プロバイダーの概念
ここでは、UI オートメーション プロバイダーを実装するために理解しておく必要がある重要な概念について簡単に説明します。
Elements
UI Automationの要素とは、UI オートメーション クライアントからアクセス可能なuser interface (UI) の部品です。 たとえば、アプリケーション ウィンドウ、ペイン、ボタン、ツールヒント、リスト ボックス、およびリスト項目があります。
Navigation
UI Automationの要素は、UI Automation ツリーとしてクライアントに公開されます。 UI Automationは、1 つの要素から別の要素へのナビゲーションによってこのツリーを構築します。 このナビゲーションは、各要素のプロバイダーによって可能になります。プロバイダーはそれぞれ、親、兄弟、または子をポイントします。
UI Automation ツリーのクライアント ビューの詳細については、「UI オートメーション ツリーの概要」を参照してください。
ビュー
クライアントが UI Automation ツリーを参照するときのビューは、主に次の表に示す 3 つです。
未加工ビュー |
すべての要素が含まれます。 |
コントロール ビュー |
コントロールである要素が含まれます。 |
コンテンツ ビュー |
コンテンツを持つ要素が含まれます。 |
UI Automation ツリーのクライアント ビューの詳細については、「UI オートメーション ツリーの概要」を参照してください。
要素がコンテンツ要素かコントロール要素かは、プロバイダー実装側で定義されます。 コントロール要素は、コンテンツ要素でもあるものとそうでないものがありますが、コンテンツ要素はすべてコントロール要素です。
フレームワーク
フレームワークは、画面上の特定の領域での子コントロール、ヒット テスト、およびレンダリングを管理するコンポーネントです。 たとえば、Win32 ウィンドウ (一般に HWND と呼ばれるものです) は、フレームワークとしての働きを持ち、メニュー バー、ステータス バー、ボタンなどの複数の UI Automation要素を格納できます。
リスト ボックスやツリー ビューなどの Win32 コンテナー コントロールは、子項目のレンダリングおよびヒット テスト実行のための独自のコードが格納されるので、フレームワークと見なされます。 対照的に、WPF リスト ボックスはフレームワークではありません。レンダリングとヒット テストは、このコントロールを格納している WPF ウィンドウによって処理されるからです。
アプリケーション内の UI を構成するフレームワークの種類が、それぞれ異なっていてもかまいません。 たとえば、HWND アプリケーション ウィンドウに Dynamic HTML (DHTML) を格納し、HWND 内にコンボ ボックスなどのコンポーネントを格納することも可能です。
フラグメント
フラグメントは、特定のフレームワークからの要素のサブツリー全体を指します。 サブツリーのルート ノードにある要素を、"フラグメント ルート" と呼びます。 フラグメント ルートには親がありませんが、他のフレームワーク (通常は Win32 ウィンドウ (HWND)) の中でホストされます。
ホスト
各フラグメントのルート ノードは、1 つの要素 (通常は Win32 ウィンドウ (HWND)) の中でホストされている必要があります。 他の要素内でホストされないデスクトップは例外です。 カスタム コントロールのホストは、そのコントロール自体の HWND です。アプリケーション ウィンドウや、その他の最上位コントロールのグループを格納できるウィンドウではありません。
フラグメントのホストは、UI Automation サービスの提供において重要な役割を果たします。 ホストによって、フラグメント ルートへのナビゲーションが可能になり、一部の既定のプロパティも設定されるので、カスタム プロバイダーではこれらを実装する必要がありません。