Använda API:t för aktiveringskontexten

Program kan hantera en aktiveringskontext genom att anropa funktionerna för aktiveringskontext direkt. Aktiveringskontexter är datastrukturer i minnet. Systemet kan använda informationen i aktiveringskontexten för att omdirigera ett program för att läsa in en viss DLL-version, COM-objektinstans eller anpassad fönsterversion. Mer information finns i Kontextreferens för aktivering.

Programprogrammeringsgränssnittet (API) kan användas för att hantera aktiveringskontexten och skapa versionsnamnsobjekt med manifest. Följande två scenarier visar hur ett program kan hantera en aktiveringskontext genom att anropa funktionerna för aktiveringskontext direkt. I de flesta fall hanteras dock aktiveringskontexten av systemet. Programutvecklare och sammansättningsleverantörer behöver vanligtvis inte göra anrop till stacken för att hantera aktiveringskontexten.

• Processer och applikationer som implementerar indirekta eller förmedlingslager.

  Till exempel en användare som hanterar aktiveringskontexter i händelseloopen. Varje gång fönstret nås, till exempel genom att flytta musen över fönstret, anropas ActivateActCtx, som aktiverar den aktuella aktiveringskontexten för resursen, enligt följande kodfragment.

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

I följande kodfragment aktiverar API-funktionen lämpliga aktiveringskontexter innan du anropar CallWindowProc. När CallWindowProc anropas används den här kontexten för att skicka ett meddelande till Windows. När alla resursåtgärder har slutförts inaktiverar funktionen kontexten.

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

• Delegerarens distributionslager.

  Det här scenariot gäller för chefer som hanterar flera entiteter med ett gemensamt API-lager, till exempel en drivrutinshanterare. Även om det ännu inte har implementerats, skulle ett exempel på detta vara ODBC-drivrutinen.

  I det här scenariot kan mellanlagret bearbeta sammansättningsbindningar. För att hämta den versionsspecifika bindningsdrivrutinen måste utgivare tillhandahålla ett manifest och ange beroenden för specifika komponenter i manifestet. Basprogrammet binder inte dynamiskt till komponenterna. vid körning hanterar drivrutinshanteraren anropen. När ODBC-drivrutinen anropas baserat på anslutningssträngen läser den in lämplig drivrutin. Sedan skapas aktiveringskontexten med hjälp av informationen i sammansättningsmanifestfilen.

  Utan manifestet är standardåtgärden för drivrutinen att använda samma kontext som den som anges av programmet– i det här exemplet version 2 av MSVCRT. Eftersom det finns ett manifest upprättas en separat aktiveringskontext. När ODBC-drivrutinen körs binder den till version 1 av MSVCRT-sammansättningen.

  Varje gång drivrutinshanteraren anropar distributionslagret, till exempel för att hämta nästa uppsättning data, använder den lämpliga sammansättningar baserat på aktiveringskontexten. Följande kodfragment illustrerar detta.

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