호스트된 구성 요소에서 콜백 사용

호스팅된 구성 요소의 콜백은 호스팅을 가능하게 합니다. 그러나 호스팅하는 구성 요소가 플러그 인 또는 자체 구성 요소에 액세스하는 데 사용하는 다른 활성화 컨텍스트를 활성화했을 수 있습니다. 이 경우 호스트된 구성 요소가 자체 COM 개체를 참조하는 스택에 활성화 컨텍스트를 남기면 호스팅 애플리케이션은 CoCreateInstance 를 호출하여 자체 구현으로 예상되는 개체를 가져와 호스트된 구성 요소의 개체를 대신 받을 수 있습니다. 이러한 활성화 컨텍스트 상속을 방지하려면 적절한 호스팅 애플리케이션이 콜백 중에 먼저 잘 알려진 자체 활성화 컨텍스트를 활성화해야 합니다.

호스팅 애플리케이션의 코드를 보호하는 다음 예제를 고려합니다.

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

이렇게 하면 Funct의 일부 내부 구현에 요청을 전달하기 전에 적절한 활성화 컨텍스트가 설정 됩니다. 사용자 고유의 구현에는 실제 구현이 인라인으로 있을 수 있지만 이전 메서드는 위임된 래퍼만 만들어 보다 쉽게 상호 운용성을 보장합니다. 일반(비 COM) 콜백을 노출할 때 비슷한 메서드를 사용하는 것이 좋습니다.