Uso dei callback da componenti ospitati

I callback dai componenti ospitati sono ciò che rende possibile l'hosting. Tuttavia, è possibile che il componente che si sta ospitando abbia attivato un altro contesto di attivazione che usa per accedere a plug-in o componenti propri. In questo caso, se il componente ospitato lascia un contesto di attivazione nello stack che fa riferimento al proprio oggetto COM, l'applicazione host potrebbe chiamare CoCreateInstance per ottenere un oggetto che prevede di essere la propria implementazione e ricevere invece l'oggetto del componente ospitato. Per evitare questa ereditarietà dei contesti di attivazione, una buona applicazione di hosting deve attivare prima il proprio contesto di attivazione noto durante un callback.

Si consideri l'esempio seguente che protegge il codice dell'applicazione host:

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;
}

In questo modo si garantisce che venga impostato un contesto di attivazione appropriato prima di passare la richiesta a un'implementazione interna di Funct. La propria implementazione può avere l'implementazione effettiva inline, ma il metodo precedente garantisce un'interoperabilità più semplice creando solo wrapper delegati. È consigliabile usare un metodo simile quando si espongono callback normali (non COM).