Usando a API de contexto de ativação

As aplicações podem gerir um de contexto de ativação chamando diretamente as funções de contexto de ativação. Os contextos de ativação são estruturas de dados na memória. O sistema pode usar as informações no contexto de ativação para redirecionar um aplicativo para carregar uma versão DLL específica, instância de objeto COM ou versão de janela personalizada. Para obter mais informações, consulte Referência do Contexto de Ativação.

A Interface de Programação de Aplicações (API) pode ser usada para gerir o contexto de ativação e criar objetos nomeados por versão com manifests . Os dois cenários a seguir ilustram como um aplicativo pode gerenciar um contexto de ativação chamando diretamente as funções de contexto de ativação. Na maioria dos casos, no entanto, o contexto de ativação é gerenciado pelo sistema. Os desenvolvedores de aplicações e fornecedores de assembly geralmente não precisam realizar chamadas à pilha para gerir o contexto de ativação.

• Processos e aplicativos que implementam camadas de indirection ou dispatch.

  Por exemplo, um usuário gerenciando contextos de ativação no loop de eventos. Cada vez que a janela é acessada, como movendo o mouse sobre a janela, ActivateActCtx é chamado, o que ativa o contexto de ativação atual para o recurso, conforme mostrado no fragmento de código a seguir.

HANDLE hActCtx;  
CreateWindow();  
...  
GetCurrentActCtx(&ActCtx);  
...  
ReleaseActCtx(&ActCtx);  

No fragmento de código a seguir, a função API ativa os contextos de ativação apropriados antes de chamar CallWindowProc. Quando CallWindowProc é chamado, ele usa esse contexto para passar uma mensagem para o Windows. Quando todas as operações de recursos forem concluídas, a função irá desativar o contexto.

ULONG_PTR ulpCookie;  
HANDLE hActCtx;  
if(ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    CallWindowProc(...);  
    ...  
    DeactivateActCtx(0, ulpCookie);  
}

• Camada de despacho do delegador.

  Esse cenário se aplica a gerentes que gerenciam várias entidades com uma camada de API comum, como um gerenciador de driver. Embora ainda não tenha sido implementado, um exemplo disso seria o driver ODBC.

  Nesse cenário, a camada intermediária torna-se capaz de processar ligações de montagem. Para obter o driver de vinculação específico da versão, os editores devem fornecer um manifesto e especificar dependências em componentes específicos nesse manifesto. A aplicação base não se liga dinamicamente aos componentes; Em tempo de execução, o gerente de driver gerencia as chamadas. Quando o driver ODBC é chamado com base na cadeia de conexão, ele carrega o driver apropriado. Em seguida, ele cria o contexto de ativação usando as informações no arquivo de manifesto do assembly.

  Sem o manifesto, a ação padrão para o driver é usar o mesmo contexto especificado pelo aplicativo — neste exemplo, a versão 2 do MSVCRT. Uma vez que existe um manifesto, um contexto de ativação separado é estabelecido. Quando o driver ODBC é executado, ele se liga à versão 1 do assembly MSVCRT.

  Cada vez que o gerente de controladores chama a camada de distribuição, por exemplo, para obter o próximo conjunto de dados, ele utiliza os assemblies apropriados com base no contexto de ativação. O fragmento de código a seguir ilustra isso.

HANDLE hActCtx;  
ULONG_PTR ulpCookie;  
ACTCTX ActCtxToCreate = {...};  
hActCtx = CreateActCtx(&ActCtxToCreate);  
...;  
if (ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    ConnectDb(...);  
    DeactivateActCtx(0, ulpCookie);  
}  
... 
ReleaseActCtx(hActCtx);