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

Именование экземпляра объекта в общем случае требует указания двух элементов: методов объекта и его перманентных данных. Известно, что СОМ не предоставляет способа именования экземпляра объекта. В СОМ технологии клиент может создать абстрактный экземпляр объекта, вызвав СоСгеatelnstance и передав ей соответствующий CLSID. Таким образом, клиет должен знать CLSID и место хранения перманентных данных, если таковые у него предусмотрены, т. е. в чистом виде СОМ не предоставляет клиенту простого решения.

Отметим, что СОМ-объект, реализующий пользовательский интерфейс должен реализовывать и интерфейс IPersistFile, для того чтобы он мог инициализироваться с помощью моникера.

Определение моникеров

Моникер — это имя определенного экземпляра объекта (точнее одного конкретного сочетания некоторого CLSID и перманентных данных). При этом он сам является СОМ-объектом и поддерживает особый интерфейс IMoniker, производный от IPersistStream. У каждого моникера есть собственные перманентные данные, позволяющие ему запустить и инициализировав один экземпляр объекта, а затем передать указатель на запрошенный интерфейс клиенту. После этого объект-моникер обычно разрушается, поскольку клиент уменьшает счетчик ссылок до 0. Процесс установления связи между клиентом и объектом, на который указывает моникер, называется привязкой (binding) к объекту.

Механизм работы
• После получения указателя на интерфейс IMoniker клиент вызывает его метод BindToObject, передавая в качестве параметра IID интерфейса объекта.( BindToObject создает экземпляр указываемого моникером объекта и возвращает указатель на заданный интерфейс объекта)
• Используя перманентные данные, моникер запускает сервер, который в свою очередь создает объект. Далее загружаются перманентные данные. Моникер получает указатель на запрошенный интерфейс и возвращает его клиенту, а сам разрушается.
• Клиент получает ссылку на объект и может вызывать © его методы.
Рассмотрим пример составного элемента.

Создание моникеров

• Методы моникера являются исполняемым кодом и должны располагаться где-то в вычислительной системе. Так как моникеры — объекты СОМ то у них есть классы и CLSID, а их реализации, как и реализации других объектов СОМ, должны быть доступны. Для стандартных моникеров есть готовые реализации, и вдобавок к этому каждый может создать новый класс моникеров и присвоить ему новый CLSID.

• Очевидно, что подобно другим СОМ-объектам, они должны создаваться при помощи CoCreatelnstance и CLSID. Чаще всего этот вариант используется для нестандартных классов моникеров. Хотя у каждого из стандартных классов свой CLSID, их моникеры могут быть созданы и инициализированы с помощью системных функций. Например, для создания экземпляра файлового моникера клиент может использовать функцию CreateFileMoniker, а для создания моникера элемента — функцию CreateltemMonikei

Var pMnk: IMoniker;
CreateFileMoniker(<.FileName>, pMnk); // Получение указателя на интерфейс

Работа моникеров. Какова последовательность действий при работе моникера? Допустим, перманентные данные моникера хранятся в документе WinWord, и пользователь запрашивает у WinWord подсоединение к объекту, заданному этим моникером. WinWord необходимо только создать из этих перманентных данных композитный моникер. В процессе своей инициализации композитный моникер увидит, что содержит другие моникеры и сам вызовет системные функции для создания файлового моникера и двух других моникеров.

После активизации всех этих моникеров WinWord вызывает метод Bind-ToObject интерфейса IMoniker композитного моникера (единственного моникера, о котором он знает), передавая IID интерфейса IOleObject — интерфейса Excel указатель, который нужен WinWord. Композитный моникер попытается вызвать BindToObject моникера элемента, а не файла. Это происходит потоку, что есть вероятность того, что Excel уже запущен, в него помещен нужный файл и открыта нужная таблица. Такая последовательность приводит к оптимизации работы, предотвращая запуск лишних копий Excel.

Если нужный объект не запущен, то моникеры более мелких, фактически встроенных объектов, вызывают BindToObject для старших объектов. Используя системный реестр, моникер может транслировать расширение имени файла вроде XLS в CLSID кода, который знает, как работать с файлами этого типа. В случае с XLS моникер получает CLSID Excel. Получив, наконец, CLSID, моникер передает его CoCreatelnstance, и библиотека СОМ запускает Excel.

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

Перед вызовом метода BindToObject необходимо создать контекст его выполнения:

Var pBC: IBindCtx; CreateBindCtx(0, pBC); pMnk.BindToObject(pBC, Nil, IID_ ISum, pSum);

Вместо двух последних операторов можно использовать функцию API:

BindMoniker(pMnk, 0, IID_ISum, pSiun)

Таблица исполняемых объектов. При обращении клиента к моникеру может оказаться, что интересуемый объект загружен и инициализирован другим клиентом. Естественно, что моникер должен подключиться с активным объектом. Для обеспечения этой возможности система поддерживает объект-таблицу исполняемых объектов. Исполняемый объект регистрируется в этом объекте-таблице, поддерживающим интерфейс IRunningObjectTable (методы Register, Revoke, GetObject).

Комментарии запрещены.