Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Os aplicativos de tecnologia assistiva precisam se comunicar entre os limites do processo para obter informações da interface do usuário dos servidores Microsoft Ative Accessibility e dos provedores de automação da interface do usuário da Microsoft. Este tópico descreve os principais problemas de comunicação entre processos que você precisa ter em mente ao desenvolver aplicativos de acessibilidade do Windows.
Quando os aplicativos usam a API de Automação do Windows, os componentes de tempo de execução Microsoft Ative Accessibility e UI Automation lidam automaticamente com todos os problemas e complexidades envolvidos na execução de comunicações entre processos (IPC), incluindo os problemas de interoperabilidade envolvidos quando um processo é de 32 bits e o outro é de 64 bits. A Microsoft reconhece que há ocasiões em que um aplicativo de tecnologia assistiva pode precisar usar alguma forma de IPC em vez da API de Automação do Windows para se comunicar com um servidor Microsoft Ative Accessibility ou provedor de Automação da Interface do Usuário. Nessas ocasiões, a Microsoft recomenda que você use mensagens DCOM ou Windows (aquelas com valores inferiores ao de WM_USER) para se comunicar com outros processos. Como a API de automação do Windows, as mensagens DCOM e Windows lidam automaticamente com todos os problemas de IPC para você, incluindo interoperabilidade de 32 bits a 64 bits.
Quando as mensagens da API de Automação do Windows, DCOM e Windows não forem uma opção, tenha em mente os seguintes problemas ao implementar o método IPC escolhido:
- Memória compartilhada—Ao usar a memória compartilhada, esteja ciente de que uma estrutura em um processo de 32 bits pode ter um tamanho e layout diferentes da mesma estrutura em um processo de 64 bits. Isso é especialmente verdadeiro para estruturas que contêm ponteiros ou alças.
- Truncamento de ponteiro — Embora um aplicativo de 32 bits possa usar o tipo de dados LONGLONG para armazenar um valor de 64 bits, há instâncias em que não existe nenhum elemento de API do Windows que permita que o aplicativo de 32 bits receba um valor de 64 bits de um processo de 64 bits ou envie um valor de 64 bits para um processo de 64 bits. Por exemplo, o GetWindowLongPtr e funções SendMessage truncam todos os valores de ponteiro, deixando o aplicativo de 32 bits com um valor inútil.
- Identificadores — Como os identificadores kernel32 e user32 são significativos apenas em 32 bits em processos de 32 bits e 64 bits, eles podem ser transferidos entre processos sem problemas. No entanto, alguns itens que o Windows define como identificadores são, na verdade, apenas ponteiros encapsulados (por exemplo, HTREEITEM). Esses "identificadores" serão truncados se forem passados de um processo de 64 bits para um processo de 32 bits.
- WinEvent Hook Functions—Para registrar uma função de gancho no contexto com um processo de servidor de 32 bits, a função hook deve residir em uma DLL de 32 bits. Da mesma forma, para registrar uma função de gancho no contexto com um processo de servidor de 64 bits, a função de gancho deve residir em uma DLL de 64 bits. Se um aplicativo de tecnologia assistiva tentar registrar uma função de gancho no contexto com um servidor que tenha uma profundidade de bits diferente, os eventos ainda serão entregues à função de gancho, mas serão entregues fora do contexto. Para obter mais informações, consulte WinEvents and In-Context and Out-of-Context Hook Functions.
Para obter mais informações sobre interoperabilidade de 32 bits e 64 bits, consulte Process Interoperability.
Tópicos relacionados