Моникеры часто составляются из других моникеров, чтобы с помощью текстового описания пути можно было осуществлять навигацию по иерархиям объектов. Чтобы обеспечить простую поддержку этого типа управления, в СОМ предусмотрена стандартная реализация моникеров, которая, будучи поставленной справа от другого моникера, запрашивает объект связать ссылку с другим объектом в иерархии. Такой моникер называется моникером элемента ( Item Moniker ) и использует интерфейс объекта IOleItemContainer для преобразования имени объекта в интерфейсный указатель.
Следующее отображаемое имя показывает, как моникер элемента использован в тандеме с классовым моникером:
clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus
Отметим использование символа " ! " для отделения отображаемого имени Class Moniker от имени элемента (item name) «Ursus». При анализе MkParseDisplayName сначала использует префикс " clsid " в качестве ProgID для контакта с реализацией Сlass Moniker . Затем MkParseDisplayName предложит реализации Class Moniker проанализировать часть строки – столько, сколько она сможет распознать. Это означает, что после того, как Сlass Moniker извлек свой GUID из строки, ее следующий фрагмент все еще нуждается в анализе: !Ursus
Поскольку это имя имеет смысл только в области действия объекта, именованного моникером слева от него, фактически MkParseDisplayName присваивает значение крайнему левому моникеру (моникеру классового типа) и запрашивает объект, который он именует (объект класса Gorilla) проанализировать оставшуюся часть строки. Для поддержки анализа отображаемых имен СОМ определяет стандартный интерфейс IParseDisplayName :
[ object,uuid(0000011a-0000-0000-C000-000000000046) ]
interface IParseDisplayName : IUnknown
{
// convert display name to a moniker
// преобразуем отображаемое имя в моникер
HRESULT ParseDisplayName( [in, unique] IBindCtx *pbc, [in] LPOLESTR pszDisplayName, [out] ULONG *pchEaten, [out] IMoniker **ppmkOut );
}
В случае отображаемого имени, использованного в этом примере, объекту класса Gorilla потребуется реализовать IParseDisplayName и преобразовать строку " !Ursus " в моникер, который MkParseDisplayName поставит справа от моникера классового типа. Поскольку требуется стандартный моникер элемента, то достаточно будет такой реализации:
STDMETHODIMP GorillaClass::ParseDisplayName(IBindCtx *pbc, LPOLESTR pszDisplayName, ULONG *pchEaten, IMoniker **ppmkOut)
{
// create an item moniker using explicit API function
// создаем отдельный моникер, используя явную API-функцию
HRESULT hr = CreateItemMoniker(OLESTR("!"), pszDisplayName + 1, ppmkOut);
// indicate how many characters were parsed
// показываем, сколько символов было проанализировано
if (SUCCEEDED(hr)) *pchEaten = wcslen(pszDisplayName);
else *pchEaten = 0; return hr;
}
Отметим, что в данном примере не делается попытки проверить правильность анализируемого имени. Здесь просто убирается начальный символ "!", и из оставшейся части отображаемого имени создается новый моникер элемента.
Так как было проанализировано два моникера, то 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 , позволяет клиенту менять стратегию связывания просто путем чтения различных отображаемых имен из файла конфигурации или из ключа реестра. |
Главная
Каталог файлов
