Creates a file moniker based on the specified path.

WINOLEAPI CreateFileMoniker(

LPCOLESTR lpszPathName,
//Pathname to be used
//Receives the file moniker



Points to a zero-terminated string containing the path on which this moniker is based. For Win32 applications, the LPCOLESTR type indicates a wide character string (two bytes per character); otherwise, the string has one byte per character.


Receives an IMoniker interface pointer to the new file 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 an error in the syntax of a path was encountered while creating a moniker.


Indicates insufficient memory.


should be called by moniker providers, to create a file moniker when that is suitable for identifying its objects. Moniker providers hand out monikers to identify their objects so they are accessible to other parties. You must use file monikers if the objects being identified are stored in files. If each object resides in its own file, file monikers are the only type you need. For objects smaller than a file, you need to use another type of moniker (for example, item monikers) in addition to file monikers. Your objects must also implement the IPersistFile interface for them to be loaded when a file moniker is bound.

The most common example of moniker providers are OLE server applications that support linking. For OLE server applications that support linking only to file-based documents in their entirety, file monikers are the only type of moniker needed. OLE server applications that support linking to objects smaller than a document (such as sections of a document or embedded objects), must use item monikers as well as file monikers.

The lpszPathName can be a relative path, a UNC path (e.g., \\server\share\path), or a drive letter based path (e.g., c:\). If based on a relative path, the resulting moniker will need to be composed onto another file moniker before it can be bound.

A file moniker cannot be composed to the right of any other kind of moniker. It is possible to compose two file monikers together if the first moniker is based on an absolute path and the other is a relative path, resulting in a single file moniker based on the combination of the two paths. To identify objects stored within a file, it is necessary to compose other types of monikers (usually item monikers) to the right of a file moniker.

See Also

IMoniker - File 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