Callbacks van gehoste onderdelen gebruiken

Callbacks van gehoste onderdelen maken hosting mogelijk. Het is echter mogelijk dat het onderdeel dat u host, een andere activeringscontext heeft geactiveerd die wordt gebruikt voor toegang tot invoegtoepassingen of onderdelen ervan. Als het gehoste onderdeel in dit geval een activeringscontext op de stack verlaat die verwijst naar een eigen COM-object, kan de hostingtoepassing CoCreateInstance aanroepen om een object te verkrijgen dat naar verwachting een eigen implementatie is en in plaats daarvan het object van het gehoste onderdeel ontvangt. Om deze overname van activeringscontexten te voorkomen, moet een goede hostingtoepassing eerst een eigen bekende activeringscontext activeren tijdens een callback.

Bekijk het volgende voorbeeld dat de code van de hostingtoepassing beveiligt:

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

Dit zorgt ervoor dat een juiste activeringscontext wordt ingesteld voordat de aanvraag wordt doorgegeven aan een interne implementatie van Funct. Uw eigen implementatie kan de werkelijke implementatie inline hebben, maar de voorgaande methode zorgt voor eenvoudigere interoperabiliteit door alleen gedelegeerde wrappers te maken. Het wordt aanbevolen om een vergelijkbare methode te gebruiken bij het weergeven van normale (niet-COM)-callbacks.