Creates a file moniker based on the specified path.
| LPCOLESTR lpszPathName,
||//Pathname to be used
| LPMONIKER FAR *ppmk
||//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
Indicates the moniker was created successfully.
Indicates an error in the syntax of a path was encountered while creating a
Indicates insufficient memory.
CreateFileMoniker 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.
can be a relative path, a UNC path (e.g., \\server
), 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.
IMoniker - File Moniker Implementation
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages