Uso dell'API del contesto di attivazione

Le applicazioni possono gestire un contesto di attivazione chiamando direttamente le funzioni del contesto di attivazione. I contesti di attivazione sono strutture di dati in memoria. Il sistema può usare le informazioni nel contesto di attivazione per reindirizzare un'applicazione per caricare una determinata versione dll, un'istanza dell'oggetto COM o una versione personalizzata della finestra. Per altre informazioni, vedere Riferimento al contesto di attivazione.

L'API (Application Programming Interface) può essere usata per gestire il contesto di attivazione e creare oggetti denominati dalla versione con manifesti. I due scenari seguenti illustrano come un'applicazione può gestire un contesto di attivazione chiamando direttamente le funzioni del contesto di attivazione. Nella maggior parte dei casi, tuttavia, il contesto di attivazione viene gestito dal sistema. Gli sviluppatori di applicazioni e i provider di assembly non devono in genere effettuare chiamate allo stack per gestire il contesto di attivazione.

• Processi e applicazioni che implementano livelli indiretti o dispatch.

  Ad esempio, un utente che gestisce i contesti di attivazione nel ciclo di eventi. Ogni volta che si accede alla finestra, ad esempio spostando il mouse sulla finestra, viene chiamato ActivateActCtx , che attiva il contesto di attivazione corrente per la risorsa, come illustrato nel frammento di codice seguente.

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

Nel frammento di codice seguente, la funzione API attiva i contesti di attivazione appropriati prima di chiamare CallWindowProc. Quando viene chiamato CallWindowProc , usa questo contesto per passare un messaggio a Windows. Al termine di tutte le operazioni sulle risorse, la funzione disattiva il contesto.

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

• Livello di invio delegato.

  Questo scenario si applica ai manager che gestiscono più entità con un livello API comune, ad esempio gestione driver. Anche se non è ancora stato implementato, un esempio di questo sarebbe il driver ODBC.

  In questo scenario, il livello intermedio diventa in grado di elaborare associazioni di assembly. Per ottenere il driver di associazione specifico della versione, gli editori devono fornire un manifesto e specificare dipendenze da componenti specifici in tale manifesto. L'applicazione di base non viene associata dinamicamente ai componenti; in fase di esecuzione, gestione driver gestisce le chiamate. Quando il driver ODBC viene chiamato in base alla stringa di connessione, carica il driver appropriato. Crea quindi il contesto di attivazione usando le informazioni nel file manifesto dell'assembly.

  Senza il manifesto, l'azione predefinita per il driver consiste nell'usare lo stesso contesto specificato dall'applicazione, in questo esempio la versione 2 di MSVCRT. Poiché esiste un manifesto, viene stabilito un contesto di attivazione separato. Quando il driver ODBC viene eseguito, viene associato alla versione 1 dell'assembly MSVCRT.

  Ogni volta che gestione driver chiama il livello dispatch, ad esempio per ottenere il set successivo di dati, usa gli assembly appropriati in base al contesto di attivazione. Il frammento di codice seguente illustra questo.

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