Client-Side UI Automation Provider Implementation
Actualización: noviembre 2007
Several different interfaz de usuario (UI) frameworks are in use within Microsoft operating systems, including Win32, formularios Windows Forms, and Windows Presentation Foundation (WPF). Automatización de la interfaz de usuario de Microsoft exposes information about UI elements to clients. However, Automatización de la interfaz de usuario does not itself have awareness of the different types of controls that exist in these frameworks and the techniques that are needed to extract information from them. Instead, it leaves this task to objects called providers. A provider extracts information from a specific control and hands that information to Automatización de la interfaz de usuario, which then presents it to the client in a consistent manner.
Providers can exist either on the server side or on the client side. A server-side provider is implemented by the control itself. WPF elements implement providers, as can any third-party controls written with Automatización de la interfaz de usuario in mind.
However, older controls such as those in Win32 and formularios Windows Forms do not directly support Automatización de la interfaz de usuario. These controls are served instead by providers that exist in the client process and obtain information about controls using cross-process communication; for example, by monitoring windows messages to and from the controls. Such client-side providers are sometimes called proxies.
Windows Vista supplies providers for standard Win32 and formularios Windows Forms controls. In addition, a fallback provider gives partial Automatización de la interfaz de usuario support to any control that is not served by another server-side provider or proxy but has a Microsoft Active Accessibility implementation. All these providers are automatically loaded and available to client applications.
For more information on support for Win32 and formularios Windows Forms controls, see UI Automation Support for Standard Controls.
Applications can also register other client-side providers.
Este tema contiene las secciones siguientes.
- Distributing Client-Side Providers
- Registering and Configuring Client-Side Providers
- Temas relacionados
Distributing Client-Side Providers
Automatización de la interfaz de usuario expects to find client-side providers in a managed-code assembly. The namespace in this assembly should have the same name as the assembly. For example, an assembly called ContosoProxies.dll would contain the ContosoProxies namespace. Within the namespace, create a UIAutomationClientSideProviders class. In the implementation of the static ClientSideProviderDescriptionTable field, create an array of ClientSideProviderDescription structures describing the providers.
Registering and Configuring Client-Side Providers
Client-side providers in a biblioteca de vínculos dinámicos (DLL) are loaded by calling RegisterClientSideProviderAssembly. No further action is required by a client application to make use of the providers.
Providers implemented in the client's own code are registered by using RegisterClientSideProviders. This method takes as an argument an array of ClientSideProviderDescription structures, each of which specifies the following properties:
A callback function that creates the provider object.
The class name of the controls that the provider will serve.
The image name of the application (usually the full name of the executable file) that the provider will serve.
Flags that govern how the class name is matched against window classes found in the target application.
The last two parameters are optional. The client might specify the image name of the target application when it wants to use different providers for different applications. For example, the client might use one provider for a Win32 list view control in a known application that supports the Multiple View pattern, and another for a similar control in another known application that does not.