UI オートメーション プロバイダーの概要
Note
このドキュメントは、System.Windows.Automation 名前空間で定義されているマネージド UI オートメーション クラスを使用する .NET Framework 開発者を対象としています。 UI オートメーションの最新情報については、Windows Automation API の「UI オートメーション」を参照してください。
UI オートメーション プロバイダーを使用すれば、コントロールで UI オートメーション クライアント アプリケーションと通信することができます。 一般に、ユーザー インターフェイス (UI) 内の各コントロールまたはその他の個別の要素はプロバイダーによって表現されます。 プロバイダーは、要素に関する情報を公開し、必要に応じて、クライアント アプリケーションがコントロールと対話できるようにするコントロール パターンを実装します。
通常、クライアント アプリケーションはプロバイダーと直接連動する必要はありません。 Win32、Windows フォーム、または Windows Presentation Foundation (WPF) フレームワークを使用するアプリケーション内の標準コントロールのほとんどが自動的に UI オートメーション システムに公開されます。 カスタム コントロールを実装するアプリケーションでは、それらのコントロール用の UI オートメーションシ プロバイダーを実装することもできます。クライアント アプリケーションではそれらにアクセスするために特別な手順を行う必要はありません。
このトピックでは、コントロール開発者が、特に Windows フォームと Win32 のウィンドウでのコントロールに対して UI オートメーションシ プロバイダーを実装する方法の概要について説明します。
プロバイダーの種類
UI オートメーション プロバイダーは、クライアント側プロバイダーとサーバー側プロバイダーの 2 つのカテゴリに分類されます。
クライアント側プロバイダー
クライアント側プロバイダーは、UI オートメーションシをサポートしていないか、または部分的にサポートしているアプリケーションと通信する UI オートメーション クライアントによって実装されます。 通常、クライアント側プロバイダーは Windows メッセージを送受信することによって、プロセス境界を越えてサーバーと通信します。
Win32、Windows フォーム、または WPF アプリケーション内のコントロール用の UI オートメーション プロバイダーはオペレーティング システムの一部として供給されるため、ほとんどのクライアント アプリケーションでは独自のプロバイダーを実装する必要がなく、この概要ではそれについてこれ以上説明しません。
サーバー側プロバイダー
サーバー側プロバイダーは、Win32、Windows フォーム、WPF 以外の UI フレームワークに基づくカスタム コントロールまたはアプリケーションによって実装されます。
また、サーバー側プロバイダーでは、サーバーからクライアントに要求するインターフェイスを UI オートメーション コア システムに公開することにより、プロセス境界を越えてクライアント アプリケーションと通信します。
UI オートメーション プロバイダーの概念
ここでは、UI オートメーション プロバイダーを実装するために理解しておく必要があるいくつかの重要な概念について簡単に説明します。
要素
UI オートメーション要素は、UI オートメーション クライアントからアクセス可能なユーザー インターフェイスの一部です。 例として、アプリケーション ウィンドウ、ペイン、ボタン、ツールヒント、リスト ボックス、およびリスト項目が含まれています。
［ナビゲーション］
UI オートメーション要素は、UI オートメーション ツリーとしてクライアントに公開されます。 UI オートメーションは、要素間を移動してツリーを構成します。 ナビゲーションは、親、兄弟、または子を指す要素ごとに、プロバイダーによって有効にされます。
UI オートメーション ツリーのクライアント ビューの詳細については、「UI オートメーション ツリーの概要」を参照してください。
Views
次の表に示すように、クライアントでは 3 つのプリンシパル ビューで UI オートメーション ツリーを表示できます。
| 表示 | 説明 |
|---|---|
| 列ビュー | すべての要素が含まれます。 |
| コントロール ビュー | コントロールである要素が含まれます。 |
| コンテンツ ビュー | コンテンツである要素が含まれます。 |
UI オートメーション ツリーのクライアント ビューの詳細については、「UI オートメーション ツリーの概要」を参照してください。
コンテンツ要素またはコントロール要素としての要素の定義はプロバイダー実装で行う必要があります。 コントロール要素はコンテンツ要素であることもないこともありますが、コンテンツ要素はすべてコントロール要素です。
フレームワーク
フレームワークは、画面のある領域で子コントロール、ヒット テスト、およびレンダリングを管理するコンポーネントです。 たとえば、HWND とも呼ばれる Win32 ウィンドウは、メニュー バー、ステータス バー、ボタンなどの UI オートメーション要素が複数含まれるフレームワークとして機能させることができます。
リスト ボックスやツリー ビューなどの Win32 コンテナー コントロールは、子項目をレンダリングしたり、それらに対してヒット テストを実行したりするための独自のコードが含まれているため、フレームワークと見なされます。 これに対して、WPF リスト ボックスは、包含する WPF ウィンドウによってレンダリングやヒット テストが処理されるため、フレームワークではありません。
アプリケーション内の UI はさまざまなフレームワークで構成することができます。 たとえば、HWND アプリケーション ウィンドウには、HWND 内のコンボ ボックスなどのコンポーネントを含むダイナミック HTML (DHTML) を含めることができます。
fragments
フラグメントは、特定のフレームワーク内の要素のサブツリー全体です。 サブツリーのルート ノードにある要素はフラグメント ルートと呼ばれます。 フラグメント ルートは、親がありませんが、他の何らかのフレームワーク (通常は Win32 ウィンドウ (HWND)) 内でホストされます。
Hosts
すべてのフラグメントのルート ノードは、1 つの要素 (通常は Win32 ウィンドウ (HWND)) 内でホストする必要があります。 例外は、他の要素でホストされないデスクトップです。 カスタム コントロールのホストは、アプリケーション ウィンドウやトップ レベル コントロールのグループを含めることができるその他のウィンドウではなく、コントロール自体の HWND です。
フラグメントのホストは、UI オートメーション サービスを提供するうえで重要な役割を果たします。 このホストがフラグメント ルートへの移動を可能にし、いくつかの既定のプロパティを提供するため、カスタム プロバイダーはそれらを実装する必要がありません。