次の方法で共有


UI オートメーション プロバイダーの概要

このドキュメントは、System.Windows.Automation 名前空間で定義されているマネージド UI オートメーション クラスを使用する .NET Framework 開発者を対象としています。 UI オートメーションの最新情報については、「Windows Automation API: UI オートメーション 」を参照してください。

UI オートメーション プロバイダーを使用すると、コントロールは UI オートメーション クライアント アプリケーションと通信できます。 一般に、ユーザー インターフェイス (UI) 内の各コントロールまたはその他の個別の要素は、プロバイダーによって表されます。 プロバイダーは要素に関する情報を公開し、必要に応じて、クライアント アプリケーションがコントロールと対話できるようにするコントロール パターンを実装します。

通常、クライアント アプリケーションはプロバイダーと直接連携する必要はありません。 Win32、Windows フォーム、または Windows Presentation Foundation (WPF) フレームワークを使用するアプリケーションの標準コントロールのほとんどは、UI オートメーション システムに自動的に公開されます。 カスタム コントロールを実装するアプリケーションでは、これらのコントロールの UI オートメーション プロバイダーを実装することもできます。また、クライアント アプリケーションは、コントロールにアクセスするために特別な手順を実行する必要はありません。

このトピックでは、コントロール開発者が UI オートメーション プロバイダー (特に Windows フォームおよび Win32 ウィンドウのコントロール) を実装する方法の概要について説明します。

プロバイダーの種類

UI オートメーション プロバイダーは、クライアント側プロバイダーとサーバー側プロバイダーの 2 つのカテゴリに分類されます。

クライアント側プロバイダー

クライアント側プロバイダーは、UI オートメーションをサポートしていない、または完全にサポートしていないアプリケーションと通信するために、UI オートメーション クライアントによって実装されます。 通常、クライアント側プロバイダーは、Windows メッセージを送受信することで、プロセス境界を越えてサーバーと通信します。

Win32、Windows フォーム、または WPF アプリケーションのコントロールの UI オートメーション プロバイダーはオペレーティング システムの一部として提供されるため、クライアント アプリケーションが独自のプロバイダーを実装する必要はほとんどありません。この概要では、それ以上説明しません。

サーバー側プロバイダー

サーバー側プロバイダーは、カスタム コントロール、または Win32、Windows フォーム、WPF 以外の UI フレームワークに基づくアプリケーションによって実装されます。

サーバー側プロバイダーは、UI オートメーション コア システムにインターフェイスを公開することで、プロセス境界を越えてクライアント アプリケーションと通信し、クライアントからの要求を処理します。

UI オートメーション プロバイダーの概念

このセクションでは、UI オートメーション プロバイダーを実装するために理解する必要がある主要な概念の一部について簡単に説明します。

元素

UI オートメーション要素は、UI オートメーション クライアントに表示されるユーザー インターフェイス (UI) の一部です。 たとえば、アプリケーション ウィンドウ、ウィンドウ、ボタン、ヒント、リスト ボックス、リスト アイテムなどがあります。

UI オートメーション要素は、UI オートメーション ツリーとしてクライアントに公開されます。 UI オートメーションは、ある要素から別の要素に移動してツリーを構築します。 ナビゲーションは、各要素のプロバイダーによって有効になり、それぞれの要素が親、兄弟、および子を指している可能性があります。

UI オートメーション ツリーのクライアント ビューの詳細については、「 UI オートメーション ツリーの概要」を参照してください。

見解

クライアントは、次の表に示すように、3 つのプリンシパル ビューで UI オートメーション ツリーを表示できます。

表示 説明
未加工ビュー すべての要素を含みます。
コントロール ビュー コントロールである要素を格納します。
コンテンツ ビュー コンテンツを含む要素を含みます。

UI オートメーション ツリーのクライアント ビューの詳細については、「 UI オートメーション ツリーの概要」を参照してください。

要素をコンテンツ要素またはコントロール要素として定義するのは、プロバイダーの実装の役割です。 コントロール要素はコンテンツ要素である場合とそうでない場合がありますが、すべてのコンテンツ要素はコントロール要素です。

フレームワーク

フレームワークは、画面の領域で子コントロール、ヒット テスト、レンダリングを管理するコンポーネントです。 たとえば、HWND と呼ばれる Win32 ウィンドウは、メニュー バー、ステータス バー、ボタンなど、複数の UI オートメーション要素を含むフレームワークとして機能できます。

リスト ボックスやツリー ビューなどの Win32 コンテナー コントロールは、子項目をレンダリングしてヒット テストを実行するための独自のコードが含まれているため、フレームワークと見なされます。 一方、WPF リスト ボックスはフレームワークではありません。レンダリングとヒット テストは、含まれている WPF ウィンドウによって処理されるためです。

アプリケーションの UI は、さまざまなフレームワークで構成できます。 たとえば、HWND アプリケーション ウィンドウには動的 HTML (DHTML) が含まれている場合があります。動的 HTML (DHTML) には、HWND のコンボ ボックスなどのコンポーネントが含まれます。

断片

フラグメントは、特定のフレームワークからの要素の完全なサブツリーです。 サブツリーのルート ノードにある要素は、フラグメント ルートと呼ばれます。 フラグメント ルートには親はありませんが、他のフレームワーク (通常は Win32 ウィンドウ (HWND) 内でホストされます。

ホスト

すべてのフラグメントのルート ノードは、要素 (通常は Win32 ウィンドウ (HWND) でホストされている必要があります。 例外はデスクトップであり、他の要素ではホストされていません。 カスタム コントロールのホストはコントロール自体の HWND であり、アプリケーション ウィンドウや最上位のコントロールのグループを含む可能性があるその他のウィンドウではありません。

フラグメントのホストは、UI オートメーション サービスを提供する上で重要な役割を果たします。 フラグメント ルートへのナビゲーションを有効にし、カスタム プロバイダーがそれらを実装する必要がないように、いくつかの既定のプロパティを提供します。

こちらも参照ください