Сущность технологии СОМ. Библиотека программиста

}

Отметим, что в данном примере не делается попытки проверить правильность анализируемого имени. Здесь просто убирается начальный символ '!', и из оставшейся части отображаемого имени создается новый моникер элемента.

Так как было проанализировано два моникера, то MkParseDisplayName будет собирать эти моникеры вместе, используя групповой композитный моникер (generic composite moniker). Групповой композитный моникер просто удерживает два моникера вместе. Реализация группового композитного моникера BindToObject сначала связывает моникер справа, передавая ему указатель на моникер слева через параметр pmkToLeft. Это иллюстрируется следующим псевдокодом:

// pseudo-code from OLE32.0LL

// псевдокод из OLE32.DLL

STDMETHODIMP GenericComposite::BindToObject (IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv)

{

return m_pmkRight->BindToObject(pbc, m_pmkLeft, riid, ppv);

}

Эта реализация демонстрирует, что моникер справа является значащим только в области действия моникера, находящегося слева от него. В случае группового композитного моникера, использованного в данном примере, моникер элемента получит классовый моникер как параметр pmkToLeft во время связывания.

Ранее мы установили, что моникер элемента использует интерфейс IOleItemContainer для связывания интерфейсного указателя. Ниже приведен псевдокод для реализации моникера элемента ВindToObject:

// pseudo-code from OLE32.DLL

// псевдокод из OLE32.DLL

STDMETHODIMP ItemMoniker::BindToObject(

IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv)

{

// assume failure

// допускаем возможность сбоя

*ppv = 0;

if (pmkToLeft == 0)

//requires a scope – требуется область действия return

E_INVALIDARG;

// first bind moniker to left

// сначала привязываем моникер слева

IOleItemContainer *poic = 0;

HRESULT hr = pmkToLeft->BindToObject(pbc, 0, IID_IOleItemContainer, (void**)&poic);

if (SUCCEEDED(hr))

{

// cache the bound object in binding context

// кэшируем связанный объект в контексте связывания

pbc->RegisterObjectBound(poic);

// get bind speed from Bind Context

// получаем быстроту связывания из контекста связывания

DWORD dwBindSpeed = this->MyGetSpeedFromCtx(pbc);

// ask object for named sub-object

// запрашиваем объект об именованном подобъекте

hr = poic->GetObject(m_pszItem, dwBindSpeed, pbc, riid, ppv);

poic->Release();

}

}

Эта реализация означает, что такой код:

HRESULT GetUrsus(IApe *&rpApe)

{

const OLECHAR pwsz[] = OLESTR(«clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus»);

return CoGetObject(pwsz, 0, IID_IApe, (void**)&rpApe);

}

эквивалентен следующему:

HRESULT GetUrsus(IApe *&rpApe) {

IOleItemContainer *poic = 0;

HRESULT hr = CoGetClassObject(CLSID_Gorilla, CLSCTX_ALL,

0, IID_IOleItemContainer, (void**)&poic);

if (SUCCEEDED(hr)) {

hr = poic->GetObject(OLESTR(«Ursus»), BINDSPEED_INFINITE,

0, IID_IApe, (void**)&rpApe);

poic->Release();

}

return hr; }

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

Моникеры и сохраняемость

Обсуждение моникеров не может быть полным без обсуждения файлового моникера (File Moniker). Напомним, что СОМ предусматривает три примитива активации: привязывание к объектам класса, привязывание к новым экземплярам класса и привязывание к постоянным объектам, хранящимся в файлах. В данной главе детально анализировались первые два из этих примитивов. Третий примитив основан на API-функции СОМ CoGetInstanceFromFile:

HRESULT CoGetInstanceFromFile( [in, unique] COSERVERINFO *pcsi,

// host/security info – информация о хосте/безопасности

[in, unique] CLSID *pClsid,

// explicit CLSID (opt) – явный CLSID (opt)