모니카 레퍼런스 - MSDN 영문

http://msdn.microsoft.com/en-us/library/ms691261(VS.85).aspx

^^^^ MSDN Moniker 레퍼런스

Moniker
An object that implements the IMoniker interface. A moniker acts as a name that uniquely identifies a COM object. In the same way that a path identifies a file in the file system, a moniker identifies a COM object in the directory namespace. See also Binding.

Moniker class
An implementation of the IMoniker interface. System-supplied moniker classes include file monikers, item monikers, generic composite monikers, anti-monikers, pointer monikers, and URL monikers.

Moniker client
An application that uses monikers to acquire interface pointers to objects managed by another application.

Moniker provider
An application that makes available monikers that identify the objects it manages, so that the objects are accessible to other applications.

Monikers

A moniker in COM is not only a way to identify an object—a moniker is also implemented as an object. This object provides services allowing a component to obtain a pointer to the object identified by the moniker. This process is referred to as binding.

Monikers are objects that implement the IMoniker interface and are generally implemented in DLLs as component objects. There are two ways of viewing the use of monikers: as a moniker client, a component that uses a moniker to get a pointer to another object; and as a moniker provider, a component that supplies monikers identifying its objects to moniker clients.

OLE uses monikers to connect to and activate objects, whether they are in the same machine or across a network. A very important use is for network connections. They are also used to identify, connect to, and run OLE compound document link objects. In this case, the link source acts as the moniker provider and the container holding the link object acts as the moniker client.

This section includes the following topics:

• Moniker Clients
• Moniker Providers
• OLE Moniker Implementations

See Also

The Component Object Model

Moniker Providers

In general, a component should be a moniker provider when it allows access to one of its objects, while still controlling the object's storage. If a component is going to hand out monikers that identify its objects, it must be capable of performing the following tasks:

• On request, create a moniker that identifies an object.
• Enable the moniker to be bound when a client calls IMoniker::BindToObject on it.

A moniker provider must create a moniker of an appropriate moniker class to identify an object. The moniker class refers to a specific implementation of the IMoniker interface that defines the type of moniker created. While you can implement IMoniker to create a new moniker class, it is frequently unnecessary because OLE provides implementations of several different moniker classes, each with its own CLSID. Refer to OLE Moniker Implementations for descriptions of moniker classes that OLE provides.

See Also

Moniker Clients

OLE Moniker Implementations

Moniker Clients

Moniker clients must start by getting a moniker, and there are several ways for a moniker client to get a moniker. For example, in OLE compound documents, when the end user creates a linked item (either using Insert Object dialog, the clipboard, or drag-and drop), a moniker is embedded as part of the linked item. In that case, the programmer has minimal contact with monikers. Programmatically, if you have an interface pointer to an object that implements the IMoniker interface, you can use that to get a moniker, and there are methods on other interfaces that are defined to return monikers.

There are different kinds of monikers, which are used to identify different kinds of objects, but to a moniker client, all monikers look the same. A moniker client simply calls IMoniker::BindToObject on a moniker and gets an interface pointer to the object that the moniker identifies. Whether the moniker identifies an object as large as an entire spreadsheet or as small as a single cell within a spreadsheet, calling IMoniker::BindToObject will return a pointer to that object. If the object is already running, IMoniker::BindToObject will find it in memory. If the object is stored passively on disk, IMoniker::BindToObject will locate a server for that object, run the server, and have the server bring the object into the running state. All the details of the binding process are hidden from the moniker client. Thus, for a moniker client, using the moniker is very simple.

See Also

Moniker Providers

OLE Moniker Implementations

OLE Moniker Implementations

OLE provides implementations of several monikers for different situations, as described in the following topics:

• File Monikers
• Composite Monikers
• Item Monikers
• Anti-Monikers
• Pointer Monikers
• Class Monikers

The file, composite, and item monikers are the most frequently used monikers, because they can be used to make nearly any object in any location. Anti-moniker and pointer monikers are primarily used inside OLE but have some application in implementing custom monikers.

See Also

Moniker Clients

Moniker Providers

Compound Documents

OLE compound documents enable users working within a single application to manipulate data written in various formats and derived from multiple sources. For example, a user might insert into a word processing document a graph created in a second application and a sound object created in a third application. Activating the graph causes the second application to load its user interface, or at least that part containing tools necessary to edit the object. Activating the sound object causes the third application to play it. In both cases, a user is able to manipulate data from external sources from within the context of a single document.

OLE compound document technology rests on a foundation consisting of COM, structured storage, and .uniform data transfer. As summarized below, each of these core technologies plays a critical role in OLE compound documents:

COM

A compound document object is essentially a COM object that can be embedded in, or linked to, an existing document. As a COM object, a compound document object exposes the IUnknown interface, through which clients can obtain pointers to its other interfaces, including several, such as IOleObject, IOleLink, and IViewObject2, that provide special features unique to compound document objects.

Structured Storage

A compound document object must implement the IPersistStorage or, optionally, IPersistStream interfaces to manage its own storage. A container used to create compound documents must supply the IStorage interface, through which objects store and retrieve data. Containers almost always provide instances of IStorage obtained from OLE’s Compound Files implementation. Containers must also use an object’s IPersistStorage and/or IPersistStream interfaces.

Uniform Data Transfer

Applications that support compound documents must implement IDataObject because embedded objects and linked objects begin as data that has been transferred using special OLE clipboard formats, rather than standard Microsoft® Windows® clipboard formats. In other words, formatting data as an embedded or linked object is simply one more option provided by OLE’s uniform data transfer model.

OLE’s compound document technology benefits both software developers and users alike. Instead of feeling obligated to cram every conceivable feature into a single application, software developers are now free, if they like, to develop smaller, more focused applications that rely on other applications to supply additional features. In cases where a software developer decides to provide an application with capabilities beyond its core features, the developer can implement these additional services as separate DLLs, which are loaded into memory only when their services are required. Users benefit from smaller, faster, more capable software that they can mix and match as needed, manipulating all required components from within a single master document.

URL Monikers

The OLE moniker architecture provides a convenient programming model for working with URLs. The moniker architecture supports extensible and complete name parsing through the MkParseDisplayName(Ex) function and the IParseDisplayName and IMoniker interfaces, as well as printable names through the IMoniker::GetDisplayName method. The IMoniker interface is the way you actually use URLs you encounter, and building components that fit into the moniker architecture is the way to actually extend URL namespaces in practice.

A new system-provided moniker class, the URL moniker, provides a framework for building and using certain URLs. Because URLs frequently refer to resources across high-latency networks, the URL Moniker supports asynchronous as well as synchronous binding. The URL Moniker does not currently support Asynchronous Storage.

The following diagram shows the components involved in using URL monikers. All these components should be familiar. (See Asynchronous Monikers.)

Like all moniker clients, a user of URL Monikers typically creates and holds a reference to the moniker as well as to the bind context to be used during binding (IMoniker::BindToStorage or IMoniker::BindToObject). To support asynchronous binding, the client can implement a bind-status-callback object, which implements the IBindStatusCallback interface, and register it with the bind context using the RegisterBindStatusCallback API function. This object will receive the transport's IBinding interface during calls to IBindStatusCallback::OnStartBinding.

The URL Moniker identifies the protocol being used by parsing the URL prefix and then retrieves the IBinding interface from the transport layer. The client uses IBinding to support pausing, cancellation, and prioritization of the binding operation. The callback object also receives progress notification through IBindStatusCallback::OnProgress, data availability notification through IBindStatusCallback::OnDataAvailable, and various, other transport-layer notifications about the status of the binding. The URL moniker or specific transport layers may also request extended information from the client via IBindStatusCallback::QueryInterface, allowing the client to provide protocol-specific information that will affect the bind operation.

Callback Synchronization

The asynchronous WinInet API (used for the most common protocols) leaves the synchronization of the callback mechanism and the calling application as an exercise for the client. This is intentional because it allows the greatest degree of flexibility. The default protocols and the URL moniker implementation perform this synchronization and guarantee that single-threaded and apartment-threaded applications never have to deal with free-thread-style contention. That is, the client's IEnumFORMATETC and IBindStatusCallback interfaces are called only on their proper threads. This feature is transparent to the user of the URL mMoniker as long each thread that calls IMoniker::BindToStorage and IMoniker::BindToObject has a message queue.

The aynchronous moniker specification requires more precise control over the prioritization and management of downloads than is allowed for by either WinSock or WinInet. Accordingly, a URL moniker manages all the downloads for any given caller's thread, using—as part of its synchronization—a priority scheme based on the IBinding specification.

Media-Type Negotiation

Many application-layer Internet protocols are based on the exchange of messages in a simple, flexible format called Multipurpose Internet Mail Extensions (MIME). Although MIME originated as a standard for exchanging electronic mail messages, it is used today by a wide variety of applications to specify mutually understood data formats as MIME, or media, types. The process is called media-type negotiation.

Media types are simple strings that denote a type and subtype (such as "text/plain" or "text/HTML"). They are used to label data or qualify a request. A Web browser, for example, as part of an HTTP request-for-data or request-for-info, specifies that it is requesting "image/gif" or "image/jpeg" Media Types, to which a Web server responds by returning the appropriate media type and, if the call was a request-for-data, the data itself in the requested format.

Media-type negotiation is often similar to how existing desktop applications negotiate with the system clipboard to determine which data format to paste when a user chooses Edit/Paste or queries for formats when receiving an IDataObject pointer during a drag-and-drop operation. The subtle difference in HTTP media-type negotiation is that the client does not know ahead of time which formats the server has available. Therefore, the client specifies up-front the media types it supports, in order of greatest fidelity, and the server responds with the best available format.

URL Monikers support media-type negotiation as a way for Internet clients and servers to agree upon formats to be used when downloading data in BindToStorage operations. To support media-type negotiation, a client implements the IEnumFORMATETC interface and calls the RegisterFormatEnumerator API function to register it with the bind context. The format enumerator lists the formats the client can accept. A URL moniker translates these formats into media types when binding to HTTP URLs.

The possible media types requested by the client are represented to URL monikers through FORMATETC structures available from the IEnumFORMATETC enumerator registered by the caller on the bind context: Each FORMATETC specifies a clipboard format identifying the media type. For example, the following code fragment specifies that the media type is PostScript®.

FORMATETC fmtetc;
fmtetc.cfFormat = RegisterClipboardFormat(CF_MIME_POSTSCRIPT);
. . .

A client can set the clipboard format to the special media type CF_NULL to indicate that the default media type of the resource pointed to by the URL should be retrieved. This format is usually the last one in which the client is interested. When no enumerator is registered with the bind context, a URL Moniker works as if an enumerator containing a single FORMATETC with cfFormat=CF_NULL is available, automatically downloading the default media-type.

Whatever media type is to be used, the client is notified of the choice by means of the pformatetc argument on its IBindStatusCallback::OnDataAvailable method. The callback occurs within the context of the client's call to IMoniker::BindToStorage.

Note If received content is of an unrecognized media-type, the client automatically calls RegisterMediaTypes to register the new type.

URL Moniker API Functions

URL moniker API functions insulate developers from the complexities of creating, managing, and using URL monikers. These monikers, which are fully described in the OLE Programmer's Reference for the ActiveX® Development Kit, are as follows:

• CreateURLMoniker Function
• IsValidURL
• RegisterMediaTypes Function
• CreateFormatEnumerator
• RegisterFormatEnumerator Function
• RevokeFormatEnumerator Function
• RegisterMediaTypeClass Function
• FindMediaTypeClass Function
• GetClassFileOrMime
• UrlMkSetSessionOption

Your familiarity with these API can be as follows:

• Be familiar with CreateURLMoniker and IsValidURL if you will be using URL monikers in stand-alone applications. If you are authoring an ActiveX control, you should use IBindHost::CreateMoniker Method instead of CreateURLMoniker.
• Be familiar with RegisterMediaTypes, CreateFormatEnumerator, RegisterFormatEnumerator, and RevokeFormatEnumerator if you will be performing any MIME negotiation with URL monikers.
• Be familiar with RegisterMediaTypeClass, FindMediaTypeClass, GetClassFileOrMime, and UrlMkSetSessionsOption only if you have significant experience both with URL monikers and with COM.

Asynchronous Monikers

The OLE moniker architecture provides a consistent, extensible programming model for working with Internet objects, providing methods for parsing names, representing Universal Resource Locators (URLs) as printable names, and locating and binding to the objects represented by URL strings. (Also see URL Monikers.) Standard OLE monikers (notably, item, file, and pointer monikers), however, are inappropriate for the Internet because they are synchronous, returning a pointer to an object or its storage only at such time as all data is available. Depending on the amount of data to be downloaded, binding synchronously can tie up the client's user interface for prolonged periods.

The Internet requires new approaches to application design. Applications should be able to perform all expensive network operations asynchronously to avoid stalling the user interface. An application should be able to trigger an operation and receive notification on full or partial completion. At that point, the application should have the choice either of proceeding with the next step of the operation or providing additional information as needed. As a download proceeds, an application should also be able to provide users with progress information and the opportunity to cancel the operation at any time.

Asynchronous monikers provide these capabilities, as well as various levels of asynchronous binding behavior, while providing backwards compatibility for applications that are either unaware of or do not require asynchronous behavior. Another OLE technology, Asynchronous Storage, works with asynchronous monikers to provide asynchronous downloading of an Internet object's persistent state. The asynchronous moniker triggers the bind operation and sets up the necessary components, including storage and stream objects, byte-array objects, and notification sinks. Once the components are connected, the moniker gets out of the way and the rest of the bind is executed mainly between the components implementing the asynchronous storage components and the object.

See Also

Asynchronous vs Synchronous Monikers

Asynchronous vs. Synchronous Binding

Asynchronous vs. Synchronous Storage

Data-Pull Model vs. Data-Push Model

URL Monikers

URL Moniker Services

The URL Moniker Services (URLMON) application programming interface (API) in Microsoft® Windows® CE .NET provides an easy-to-use framework for building and using Uniform Resource Locators (URLs).

Asynchronous pluggable protocols allow you to create custom URL protocols, pluggable protocol handlers, Multipurpose Internet Mail Extensions (MIME) filters, and namespace handlers that work with a URL moniker in Microsoft Internet Explorer 5.5.

A URL security zone is a group of URL namespaces that are assigned an equal level of permission, or trust. Each URL action a browser could take that might pose a security risk to the local computer, for example running a MicrosoftActiveX® control, is assigned a URL policy. This URL policy reflects the level of trust given to the URL namespaces in that zone. The URL security zones API allows developers to manage URL security zones and create custom URL security zone managers.

Hit logging allows content providers to collect information about activity on their Web sites. These log entries contain the URL of the resource, the browsing context, whether the information was viewed from the cache, the date viewed, the time that the viewing started, the duration it was viewed, and the custom information. The hit logging API allows Web developers to verify if hit logging is enabled and to write customized entries in the log.

This documentation assumes that you have an understanding of Microsoft Win32® programming and an understanding of OLE and Component Object Model (COM) programming. An understanding of the format and syntax of URLs is also required for using the Internet-related interfaces, methods, and functions. For more information, see RFC 1738, Uniform Resource Locators (URL). You can find this document at ftp://ftp.isi.edu/in-notes/rfc1738.txt.