Utilisation de rappels à partir de composants hébergés

Les rappels des composants hébergés sont ce qui rend possible l’hébergement. Toutefois, il est possible que le composant que vous hébergez ait activé un autre contexte d’activation qu’il utilise pour accéder à des plug-ins ou à des composants propres. Dans ce cas, si le composant hébergé quitte un contexte d’activation sur la pile qui fait référence à son propre objet COM, l’application d’hébergement peut appeler CoCreateInstance pour obtenir un objet qu’elle s’attend à être sa propre implémentation et à la place recevoir l’objet du composant hébergé. Pour empêcher cet héritage de contextes d’activation, une bonne application d’hébergement doit d’abord activer son propre contexte d’activation bien connu lors d’un rappel.

Considérez l’exemple suivant qui protège le code de l’application d’hébergement :

HRESULT STDCALL 
CHostingAppFirewall::ITheInterface::FunctWrapper()
{
    ULONG_PTR ulpCookie;
    HRESULT hRes = E_FAIL;
    if (!ActivateActCtx(this->m_hHostingAppContext, &ulpCookie))
        return HRESULT_FROM_WIN32(GetLastError());
    __try 
        {
        hRes = this->m_ITheInterface->Funct();
    } 
        __finally 
        {
        if (!DeactivateActCtx(0, ulpCookie))
            hRes = HRESULT_FROM_WIN32(GetLastError());
    }
    return hRes;
}

Cela garantit qu’un contexte d’activation approprié est défini avant de transmettre la demande à une implémentation interne de Funct. Votre propre implémentation peut avoir l’implémentation réelle en ligne, mais la méthode précédente garantit une interopérabilité plus facile en créant simplement des wrappers délégués. Il est recommandé d’utiliser une méthode similaire lors de l’exposition de rappels normaux (non COM).