Implementação do provedor de automação da interface do usuário do lado do cliente
Nota
Esta documentação destina-se a desenvolvedores do .NET Framework que desejam usar as classes de automação da interface do usuário gerenciadas definidas no System.Windows.Automation namespace. Para obter as informações mais recentes sobre a automação da interface do usuário, consulte API de automação do Windows: automação da interface do usuário.
Várias estruturas de interface do usuário (UI) diferentes estão em uso nos sistemas operacionais da Microsoft, incluindo Win32, Windows Forms e Windows Presentation Foundation (WPF). A Automação da Interface do Usuário da Microsoft expõe informações sobre elementos da interface do usuário aos clientes. No entanto, a automação da interface do usuário em si não tem conhecimento dos diferentes tipos de controles que existem nessas estruturas e das técnicas necessárias para extrair informações delas. Em vez disso, ele deixa essa tarefa para objetos chamados provedores. Um provedor extrai informações de um controle específico e entrega essas informações à Automação da Interface do Usuário, que as apresenta ao cliente de maneira consistente.
Os provedores podem existir no lado do servidor ou no lado do cliente. Um provedor do lado do servidor é implementado pelo próprio controle. Os elementos do WPF implementam provedores, assim como quaisquer controles de terceiros escritos com a automação da interface do usuário em mente.
No entanto, controles mais antigos, como os do Win32 e do Windows Forms, não oferecem suporte direto à automação da interface do usuário. Em vez disso, esses controles são servidos por provedores que existem no processo do cliente e obtêm informações sobre controles usando comunicação entre processos; por exemplo, monitorando mensagens do Windows de e para os controles. Esses provedores do lado do cliente às vezes são chamados de proxies.
O Windows Vista fornece provedores para controles padrão Win32 e Windows Forms. Além disso, um provedor de fallback dá suporte parcial à Automação da Interface do Usuário a qualquer controle que não seja servido por outro provedor ou proxy do lado do servidor, mas que tenha uma implementação do Microsoft Ative Accessibility. Todos esses provedores são automaticamente carregados e disponibilizados para aplicativos cliente.
Para obter mais informações sobre o suporte para controles Win32 e Windows Forms, consulte Suporte de automação da interface do usuário para controles padrão.
Os aplicativos também podem registrar outros provedores do lado do cliente.
Distribuindo provedores do lado do cliente
A Automação da Interface do Usuário espera encontrar provedores do lado do cliente em um assembly de código gerenciado. O namespace neste assembly deve ter o mesmo nome que o assembly. Por exemplo, um assembly chamado ContosoProxies.dll conteria o namespace ContosoProxies. Dentro do namespace, crie uma UIAutomationClientSideProviders classe. Na implementação do campo estático ClientSideProviderDescriptionTable , crie uma matriz de ClientSideProviderDescription estruturas descrevendo os provedores.
Registrando e configurando provedores do lado do cliente
Os provedores do lado do cliente em uma biblioteca de vínculo dinâmico (DLL) são carregados chamando RegisterClientSideProviderAssembly. Nenhuma ação adicional é necessária por um aplicativo cliente para fazer uso dos provedores.
Os provedores implementados no próprio código do cliente são registrados usando RegisterClientSideProviders. Este método toma como argumento uma matriz de ClientSideProviderDescription estruturas, cada uma das quais especifica as seguintes propriedades:
Uma função de retorno de chamada que cria o objeto do provedor.
O nome da classe dos controles que o provedor servirá.
O nome da imagem do aplicativo (geralmente o nome completo do arquivo executável) que o provedor irá servir.
Sinalizadores que governam como o nome da classe é comparado com as classes de janela encontradas no aplicativo de destino.
Os dois últimos parâmetros são opcionais. O cliente pode especificar o nome da imagem do aplicativo de destino quando quiser usar provedores diferentes para aplicativos diferentes. Por exemplo, o cliente pode usar um provedor para um controle de exibição de lista Win32 em um aplicativo conhecido que oferece suporte ao padrão de exibição múltipla e outro para um controle semelhante em outro aplicativo conhecido que não suporta.