UI Automation Providers Overview
Actualización: noviembre 2007
UI Automation providers enable controls to communicate with UI Automation client applications. In general, each control or other distinct element in a interfaz de usuario (UI) is represented by a provider. The provider exposes information about the element and optionally implements control patterns that enable the client application to interact with the control.
Client applications do not usually have to work directly with providers. Most of the standard controls in applications that use the Win32, formularios Windows Forms, or Windows Presentation Foundation (WPF) frameworks are automatically exposed to the Automatización de la interfaz de usuario system. Applications that implement custom controls may also implement Automatización de la interfaz de usuario providers for those controls, and client applications do not have to take any special steps to gain access to them.
This topic provides an overview of how control developers implement Automatización de la interfaz de usuario providers, particularly for controls in formularios Windows Forms and Win32 windows.
Este tema contiene las secciones siguientes.
- Types of Providers
- UI Automation Provider Concepts
- Temas relacionados
Types of Providers
UI Automation providers fall into two categories: client-side providers and server-side providers.
Client-side providers
Client-side providers are implemented by UI Automation clients to communicate with an application that does not support, or does not fully support, Automatización de la interfaz de usuario. Client-side providers usually communicate with the server across the process boundary by sending and receiving Windows messages.
Because UI Automation providers for controls in Win32, formularios Windows Forms, or WPF applications are supplied as part of the operating system, client applications seldom have to implement their own providers, and this overview does not cover them further.
Server-side providers
Server-side providers are implemented by custom controls or by applications that are based on a UI framework other than Win32, formularios Windows Forms, or WPF.
Server-side providers communicate with client applications across the process boundary by exposing interfaces to the Automatización de la interfaz de usuario core system, which in turn serves requests from clients.
UI Automation Provider Concepts
This section provides brief explanations of some of the key concepts you need to understand in order to implement UI Automation providers.
Elements
Automatización de la interfaz de usuario elements are pieces of interfaz de usuario (UI) that are visible to UI Automation clients. Examples include application windows, panes, buttons, tooltips, list boxes, and list items.
Navigation
Automatización de la interfaz de usuario elements are exposed to clients as a Automatización de la interfaz de usuario tree. Automatización de la interfaz de usuario constructs the tree by navigating from one element to another. Navigation is enabled by the providers for each element, each of which may point to a parent, siblings, and children.
For more information on the client view of the Automatización de la interfaz de usuario tree, see UI Automation Tree Overview.
Views
A client can see the Automatización de la interfaz de usuario tree in three principal views, as shown in the following table.
Raw view |
Contains all elements. |
Control view |
Contains elements that are controls. |
Content view |
Contains elements that have content. |
For more information on client views of the Automatización de la interfaz de usuario tree, see UI Automation Tree Overview.
It is the responsibility of the provider implementation to define an element as a content element or a control element. Control elements may or may not also be content elements, but all content elements are control elements.
Frameworks
A framework is a component that manages child controls, hit-testing, and rendering in an area of the screen. For example, a Win32 window, often referred to as an HWND, can serve as a framework that contains multiple Automatización de la interfaz de usuario elements such as a menu bar, a status bar, and buttons.
Win32 container controls such as list boxes and tree views are considered to be frameworks, because they contain their own code for rendering child items and performing hit-testing on them. By contrast, a WPF list box is not a framework, because the rendering and hit-testing is being handled by the containing WPF window.
The interfaz de usuario in an application can be made up of different frameworks. For example, an HWND application window might contain HTML dinámico (DHTML) which in turn contains a component such as a combo box in an HWND.
Fragments
A fragment is a complete subtree of elements from a particular framework. The element at the root node of the subtree is called a fragment root. A fragment root does not have a parent, but is hosted within some other framework, usually a Win32 window (HWND).
Hosts
The root node of every fragment must be hosted in an element, usually a Win32 window (HWND). The exception is the desktop, which is not hosted in any other element. The host of a custom control is the HWND of the control itself, not the application window or any other window that might contain groups of top-level controls.
The host of a fragment plays an important role in providing Automatización de la interfaz de usuario services. It enables navigation to the fragment root, and supplies some default properties so that the custom provider does not have to implement them.