Использование API контекста активации

Приложения могут управлять контекстом активации , напрямую вызывая функции контекста активации. Контексты активации — это структуры данных в памяти. Система может использовать сведения в контексте активации для перенаправления приложения для загрузки определенной версии DLL, экземпляра COM-объекта или пользовательской версии окна. Дополнительные сведения см. в разделе Справочник по контексту активации.

Программный интерфейс приложения (API) можно использовать для управления контекстом активации и создания именованных версией объектов с манифестами. В следующих двух сценариях показано, как приложение может управлять контекстом активации, напрямую вызывая функции контекста активации. Однако в большинстве случаев контекстом активации управляет система. Разработчикам приложений и поставщикам сборок обычно не требуется выполнять вызовы к стеку для управления контекстом активации.

• Процессы и приложения, реализующие уровни косвенного обращения или диспетчеризации.

  Например, пользователь, управляющий контекстами активации в цикле событий. При каждом доступе к окну, например путем наведения указателя мыши на окно, вызывается ActivateActCtx , который активирует текущий контекст активации для ресурса, как показано в следующем фрагменте кода.

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

В следующем фрагменте кода функция API активирует соответствующие контексты активации перед вызовом CallWindowProc. При вызове CallWindowProc он использует этот контекст для передачи сообщения в Windows. После завершения всех операций с ресурсами функция отключит контекст.

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

• Уровень диспетчеризации делегатора.

  Этот сценарий применяется к менеджерам, которые управляют несколькими сущностями с общим уровнем API, например диспетчером драйверов. Хотя он еще не реализован, примером этого может быть драйвер ODBC.

  В этом сценарии средний уровень становится способным обрабатывать привязки сборок. Чтобы получить драйвер привязки для конкретной версии, издатели должны предоставить манифест и указать зависимости от определенных компонентов в этом манифесте. Базовое приложение не выполняет динамическая привязка к компонентам; во время выполнения диспетчер драйверов управляет вызовами. При вызове драйвера ODBC на основе строки подключения он загружает соответствующий драйвер. Затем он создает контекст активации, используя сведения в файле манифеста сборки.

  Без манифеста по умолчанию для драйвера используется тот же контекст, что и в приложении, — в этом примере msvcrt версии 2. Так как манифест существует, устанавливается отдельный контекст активации. При запуске драйвера ODBC он привязывается к версии 1 сборки MSVCRT.

  Каждый раз, когда диспетчер драйверов вызывает уровень диспетчеризации( например, для получения следующего набора данных), он использует соответствующие сборки на основе контекста активации. Это иллюстрирует следующий фрагмент кода.

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