Utilisation de rappels à partir de composants hébergés
Les rappels des composants hébergés sont ceux qui rendent l’hébergement possible. Toutefois, il est possible que le composant que vous hébergez ait activé un autre contexte d’activation qu’il utilise pour accéder à ses propres plug-ins ou composants. Dans ce cas, si le composant hébergé laisse 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’il s’attend à avoir sa propre implémentation et à la place recevoir l’objet du composant hébergé. Pour éviter cet héritage des contextes d’activation, une bonne application d’hébergement doit activer d’abord son propre contexte d’activation connu pendant un rappel.
Prenons 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 correct est défini avant de passer la requête sur une implémentation interne de FUNCT. Votre propre implémentation peut avoir l’implémentation Inline réelle, mais la méthode précédente garantit une plus grande interopérabilité 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).