Korzystanie z interfejsu API do zarządzania kontekstem aktywacji

Aplikacje mogą zarządzać kontekstem aktywacji przez bezpośrednie wywołanie funkcji kontekstu aktywacji. Konteksty aktywacji to struktury danych w pamięci. System może używać informacji w kontekście aktywacji, aby przekierować aplikację w celu załadowania określonej wersji biblioteki DLL, wystąpienia obiektu COM lub niestandardowej wersji okna. Aby uzyskać więcej informacji, zobacz dokumentacja kontekstu aktywacji.

Interfejs programowania aplikacji (API) może służyć do zarządzania kontekstem aktywacji i tworzenia obiektów nazwanych wersjami za pomocą manifestów . W poniższych dwóch scenariuszach pokazano, jak aplikacja może zarządzać kontekstem aktywacji przez bezpośrednie wywołanie funkcji kontekstu aktywacji. W większości przypadków kontekst aktywacji jest jednak zarządzany przez system. Deweloperzy aplikacji i dostawcy zestawów często nie muszą wykonywać wywołań do stosu w celu zarządzania kontekstem aktywacji.

• Procesy i aplikacje implementujące warstwy pośrednie lub warstwy dyspozytorskie.

  Na przykład użytkownik zarządzający kontekstami aktywacji w pętli zdarzeń. Za każdym razem, gdy jest uzyskiwany dostęp do okna, na przykład przesuwając wskaźnik myszy nad oknem, wywoływana jest ActivateActCtx, która aktywuje bieżący kontekst aktywacji zasobu, jak pokazano w poniższym fragcie kodu.

HANDLE hActCtx;  
CreateWindow();  
...  
GetCurrentActCtx(&ActCtx);  
...  
ReleaseActCtx(&ActCtx);  

W poniższym fragmentcie kodu funkcja interfejsu API aktywuje odpowiednie konteksty aktywacji przed wywołaniem CallWindowProc. Po wywołaniu CallWindowProc za pomocą używa tego kontekstu do przekazania komunikatu do systemu Windows. Po zakończeniu wszystkich operacji zasobów funkcja zdezaktywuje kontekst.

ULONG_PTR ulpCookie;  
HANDLE hActCtx;  
if(ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    CallWindowProc(...);  
    ...  
    DeactivateActCtx(0, ulpCookie);  
}

• Warstwa wysyłania delegatora.

  Ten scenariusz dotyczy menedżerów, którzy zarządzają wieloma jednostkami za pomocą wspólnej warstwy interfejsu API, takiej jak menedżer sterowników. Chociaż nie został jeszcze zaimplementowany, przykładem tego będzie sterownik ODBC.

  W tym scenariuszu warstwa środkowa może przetwarzać powiązania zestawów. Aby uzyskać sterownik powiązania dla konkretnej wersji, wydawcy muszą dostarczyć manifest i określić zależności od poszczególnych składników w tym manifeście. Aplikacja bazowa nie wiąże się dynamicznie z komponentami; podczas działania menedżer sterowników zarządza wywołaniami. Gdy sterownik ODBC jest wywoływany na podstawie parametrów połączenia, ładuje odpowiedni sterownik. Następnie tworzy kontekst aktywacji przy użyciu informacji zawartych w pliku manifestu zestawu.

  Bez manifestu domyślną akcją sterownika jest użycie tego samego kontekstu co określony przez aplikację — w tym przykładzie wersja 2 MSVCRT. Ponieważ manifest istnieje, jest ustanawiany oddzielny kontekst aktywacji. Po uruchomieniu sterownika ODBC jest on powiązany z wersją 1 zestawu MSVCRT.

  Za każdym razem, gdy menedżer sterowników wywołuje warstwę wysyłania — na przykład w celu pobrania następnego zestawu danych — używa odpowiednich zestawów na podstawie kontekstu aktywacji. Poniższy fragment kodu ilustruje to.

HANDLE hActCtx;  
ULONG_PTR ulpCookie;  
ACTCTX ActCtxToCreate = {...};  
hActCtx = CreateActCtx(&ActCtxToCreate);  
...;  
if (ActivateActCtx(hActCtx, &ulpCookie))  
{  
    ...  
    ConnectDb(...);  
    DeactivateActCtx(0, ulpCookie);  
}  
... 
ReleaseActCtx(hActCtx);