242

Перед окончанием работы программа CALLPUB отсоединяется от OLE:

// Отсоединение от библиотек OLE

CoUninitialize( );

Оба вызова необходимы, поскольку программа CALLPUB получает свой интерфейс IMalloc из сервера компонента PUBMEM с помощью вызова функции CoCreateInstance:

HRESULT hr = CoCreateInstance(CLSID_ALLOCATOR, NULL, CLSCTX_INPROC_SERVER, IID_IMalloc,

(void **) &pMalloc);

if(FAILED(hr))

{

MessageBox(hwnd, "Error: No allocator", szAppName, MB_OK); return 0;

}

Эта функция библиотеки OLE ищет в реестре компонент, который может обеспечить класс CLSID_ALLOCATOR, символ, определенный в заголовочном файле PUBMEM.Н. Чтобы заставить это слово выделять память, а не просто ссылаться на дополнительное значение, в список включенных файлов библиотеки PUBMEM добавляется следующее:

#include <initguid.h> #include "pubmem.h"

Когда писалась эта книга были определены три контекста для типов запускаемых серверов (параметр dwClsContext функции CoCreateInstance). CLSCTX_INPROC_SERVER, который запрашивается из PUBMEM, является самостоятельным DLL-сервером. Другим типом DLL-сервера, CLSCTX_INPROC_HANDLER, является локальный обработчик для cервера вне процесса клиента. Он работает как внутренний заменитель сервера процесса (быстрее, с меньшими накладными расходами) до тех пор, пока не понадобится сервер вне процесса. Третий тип контекста, CLSCTX_LOCAL_SERVER, запускается в качестве отдельного процесса на той же машине.

В отличие от закрытой функции CreateAllocator, которая всегда возвращает указатель на интерфейс IMalloc, функция CoCreateInstance позволяет вызывающей процедуре задать тип возвращаемого функцией интерфейса. PUBMEM запрашивает IDD_IMalloc, идентификатор интерфейса IMalloc. Но с тем же результатом она могла бы потребовать идентификатор IDD_IUnknown и затем выполнить вызов функции QueryInterface для указателя на интерфейс IMalloc. Конечно, если бы клиент запомнил оба указателя интерфейса, то для правильного уменьшения счетчика ссылок в конце концов потребовалось бы два вызова функции Release.

Заключение

Это введение в основы модели составного объекта (COM) OLE должно обеспечить хорошую базу для начала работы с технологиями OLE, где бы не пришлось с ними встретиться. Создаются ли контейнеры составных документов или серверы, объекты автоматизации или контроллеры, контейнеры элементов управления OLE или элементы управления OLE — в этой главе описано все, что имеет отношение к интерфейсам модели составного объекта OLE. Услуги оболочки Windows 95 доступны только через интерфейсы модели составного объекта OLE. Даже если вы собираетесь использовать библиотеки классов, например MFC компании Microsoft или OWL компании Borland, то уже при поверхностном знакомстве с ними вы обнаружите в них модель составного объекта

OLE.

Тогда, когда Windows 95 только-только начала появляться перед взорами своих создателей, Microsoft разослал разработчикам программного обеспечения важное сообщение о том, что будущее принадлежит Win32 и OLE. С появлением Windows 95 и обещанным приходом технологий OLE становится ясно, что будущее уже пришло.

Теперь у вас есть все, что нужно для того, чтобы создавать грандиозные приложения для Windows завтрашнего дня.