Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Observação
Esta documentação destina-se a desenvolvedores do .NET Framework que desejam usar as classes de Automação de Interface do Usuário gerenciadas definidas no namespace System.Windows.Automation. Para obter as informações mais recentes sobre Automação de Interface do Usuário, consulte API de Automação do Windows: Automação de Interface do Usuário.
Várias estruturas de interface do usuário (interface do usuário) diferentes estão em uso nos sistemas operacionais 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 para clientes. No entanto, a Automação da Interface do Usuário não tem reconhecimento dos diferentes tipos de controles existentes nessas estruturas e das técnicas necessárias para extrair informações deles. 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 todos os 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 dão suporte diretamente à Automação da Interface do Usuário. Em vez disso, esses controles são atendidos por provedores que existem no processo do cliente e obtêm informações sobre controles usando a 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 do Win32 e do Windows Forms. Além disso, um provedor de fallback dá suporte parcial à Automação de Interface do Usuário a qualquer controle que não seja atendido por outro provedor ou proxy do lado do servidor, mas tenha uma implementação de Acessibilidade Ativa da Microsoft. Todos esses provedores são carregados e disponíveis automaticamente para aplicativos cliente.
Para obter mais informações sobre o suporte para controles Win32 e Windows Forms, consulte Suporte à Automação de Interface do Usuário para Controles Padrão.
Os aplicativos também podem registrar outros provedores do lado do cliente.
Como distribuir 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 desse assembly deve ter o mesmo nome do assembly. Por exemplo, um assembly chamado ContosoProxies.dll conteria o namespace ContosoProxies. No namespace, crie uma UIAutomationClientSideProviders classe. Na implementação do campo estático ClientSideProviderDescriptionTable, crie uma matriz de estruturas ClientSideProviderDescription que descrevem os provedores.
Registrando e configurando provedores de Client-Side
Os provedores do lado do cliente em uma DLL (biblioteca de vínculo dinâmico) são carregados com uma chamada a RegisterClientSideProviderAssembly. Nenhuma ação adicional é necessária para que um aplicativo cliente use os provedores.
Os provedores implementados no próprio código do cliente são registrados usando RegisterClientSideProviders. Esse método usa 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 atenderá.
O nome da imagem do aplicativo (geralmente o nome completo do arquivo executável) que o provedor fornecerá.
Sinalizadores que regem como o nome da classe é correspondido 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 dá suporte ao padrão de Exibição Múltipla e outro para um controle semelhante em outro aplicativo conhecido que não o faz.