Creates an item moniker based on a string that identifies an object within a container, typically a compound document.

WINOLEAPI CreateItemMoniker(

LPCOLESTR lpszDelim,
//Delimiter string
//Item name
//Receives the item moniker



Points to a zero-terminated string containing the delimiter (typically "!") used to separate this item's display name from the display name of its container. For Win32 applications, the LPOLESTR type indicates a wide character string (two bytes per character); otherwise, the string has one byte per character.


Points to a zero-terminated string containing the container's name for the object being identified. This name can later be used to retrieve a pointer to the object in a call to IOleItemContainer::GetObject.


Receives an IMoniker pointer to the new item moniker. The returned pointer is NULL if an error occurs; if non-NULL, the function has called IUnknown::AddRef on the parameter and the caller is responsible for calling IUnknown::Release.

Return Values


Indicates the moniker was created successfully.


Indicates insufficient memory.


A moniker providerthat can identify its objects with an item moniker would call CreateItemMoniker. A moniker provider hands out monikers to identify its objects so they are accessible to other parties. Item monikers identify objects that are contained within another object and can be individually identified using a string. The container of the object must also implement the IOleContainer interface so the objects can be loaded when a item moniker is bound.

The most common example of moniker providers are OLE applications that support linking. If your OLE application supports OLE linking to objects smaller than a file-based documents, you need to use item monikers. A server application that allows linking to a selection within a document, uses item monikers to identify those objects. Container applications that allow linking to embedded objects use item monikers to identify the embedded objects.

The lpszItem parameter is the name used by the document to uniquely identify the object. For example, if the object being identified is a cell range in a spreadsheet, an appropriate name might be something like "A1:E7." If the object being identified is an embedded object, an appropriate name might be something like "embedobj1." The document containing the object must provide an implementation of the IOleItemContainer interface that can interpret the name and locate the corresponding object. This allows the item moniker to be bound to the object it identifies.

Item monikers are typically not used in isolation; they must be composed with a moniker that identifies the document that contains the object. For example, if the object being identified is a cell range contained in a file-based document, the item moniker identifying that object must be composed with the file moniker identifying that document; this results in a composite moniker like "C:\work\sales.xls!A1:E7." It's also possible to have nested containers, for example, if an object is contained within an embedded object inside another document. The complete moniker of such an object would look like "C:\work\report.doc!embedobj1!A1:E7." In such a situation, each container object must call CreateItemMoniker and provide its own implementation of the IOleItemContainer interface.

See Also

IMoniker::ComposeWith, IOleItemContainer, IMoniker - Item Moniker Implementation

Software for developers
Delphi Components
.Net Components
Software for Android Developers
More information resources
Unix Manual Pages
Delphi Examples
Databases for Amazon shops developers
Amazon Categories Database
Browse Nodes Database