次の方法で共有


ホストされるコンポーネントからのコールバックの使用

ホストされたコンポーネントからのコールバックによって、ホスティングが可能になります。 ただし、ホストしているコンポーネントが、プラグインまたは独自のコンポーネントにアクセスするために使用する別のアクティブ化コンテキストをアクティブ化している可能性があります。 この場合、ホストされるコンポーネントが独自の 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 以外の) コールバックを公開するときは、同様の方法を使用することをお勧めします。