Important:
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
A version of this page is also available for
4/8/2010

This function converts a string into a moniker that identifies the object named by the string. This is the inverse of the IMoniker::GetDisplayNameoperation, which retrieves the display name associated with a moniker.

Syntax

WINOLEAPI MkParseDisplayName(
  LPBC 
pbc,
  LPCOLESTR 
szUserName,
  ULONG FAR* 
pchEaten,
  LPMONIKER FAR* 
ppmk
);

Parameters

pbc

[in] Pointer to the IBindCtxinterface on the bind context object to be used in this binding operation.

szUserName

[in] Pointer to a zero-terminated wide character string (two bytes per character) containing the display name to be parsed.

pchEaten

[out] Pointer to the number of characters of szUserName that were consumed. If the function is successful, * pchEatenis the length of szUserName; otherwise, it is the number of characters successfully parsed.

ppmk

[out] Address of IMoniker* pointer variable that receives the interface pointer to the moniker that was built from szUserName. When successful, the function has called IUnknown::AddRefon the moniker and the caller is responsible for calling IUnknown::Release. If an error occurs, the supplied interface pointer value is NULL.

Return Value

This function supports the standard return value E_OUTOFMEMORY, as well as the following:

S_OK

The parse operation was successful and the moniker was created.

MK_E_SYNTAX

Error in the syntax of a file name or an error in the syntax of the resulting composite moniker.

This function can also return any of the error values returned by IMoniker::BindToObjector IParseDisplayName::ParseDisplayName.

Remarks

The MkParseDisplayNamefunction parses a human-readable name into a moniker that can be used to identify a link source. The resulting moniker can be a simple moniker (such as a file moniker), or it can be a generic composite made up of the component moniker pieces.

For example, the following display name

Copy Code
"c:\mydir\somefile!item 1" 

could be parsed into the following generic composite moniker.

Copy Code
(FileMoniker based on "c:\mydir\somefile") + (ItemMoniker based on
"item 1") 

The most common use of MkParseDisplayNameis in the implementation of the standard Links dialog box, which allows an end user to specify the source of a linked object by typing in a string.

Your application may also need to call MkParseDisplayNameif it supports a macro language that permits remote references (reference to elements outside of the document).

Parsing a display name often requires activating the same objects that would be activated during a binding operation, so it can be just as expensive (in terms of performance) as binding.

Objects that are bound during the parsing operation are cached in the bind context passed to the function.

If your application binds the moniker returned by MkParseDisplayName, it is best to do so immediately after the function returns, using the same bind context. This technique removes the need to activate objects a second time.

MkParseDisplayNameparses as much of the display name as it understands into a moniker. The function then calls IMoniker::ParseDisplayNameon the newly created moniker, passing the remainder of the display name.

The moniker returned by IMoniker::ParseDisplayNameis composed onto the end of the existing moniker and, if any of the display name remains unparsed, IMoniker::ParseDisplayNameis called on the result of the composition.

This process is repeated until the entire display name has been parsed.

The MkParseDisplayNamefunction attempts the following strategies to parse the beginning of the display name, using the first one that succeeds:

  1. The function looks in the Running Object Table for file monikers corresponding to all prefixes of szDisplayNamethat consist solely of valid file name characters. This strategy can identify documents that are as yet unsaved.

  2. The function checks the maximal prefix of szDisplayName, which consists solely of valid file name characters, to see if an OLE 1 document is registered by that name (this may require some DDE broadcasts). In this case, the returned moniker is an internal moniker provided by the OLE 1 compatibility layer of OLE 2.

  3. The function consults the file system to check whether a prefix of szDisplayNamematches an existing file. The file name can be drive-absolute, drive-relative, working-directory relative, or begin with an explicit network share name. This is the common case.

If the initial character of szDisplayNameis an '@', the function finds the longest string immediately following it that conforms to the legal ProgID syntax.

The function converts this string to a CLSID using the CLSIDFromProgIDfunction. If the CLSID represents an OLE 2 class, the function loads the corresponding class object and asks for an IParseDisplayNameinterface pointer.

The resulting IParseDisplayNameinterface is then given the whole string to parse, starting with the '@'. If the CLSID represents an OLE 1 class, then the function treats the string following the ProgID as an OLE1/DDE link designator having <filename>!<item> syntax.

To determine whether the platform supports this function, see Determining Supported COM APIs.

Requirements

Header objbase.h
Library ole32.lib
Windows Embedded CE Windows CE 3.0 and later
Windows Mobile Windows Mobile Version 5.0 and later

See Also