Because most OLE server applicationscan support a number of data formats, the OLE specification defines adata format convention that determines which data format a serverapplication uses to place data on the clipboard. This article explainsthe Native, OwnerLink, and ObjectLink OLE clipboard data formats.
An OLE server application must call the RegisterClipboardFormatfunction to register the Native, OwnerLink, and ObjectLink OLE dataformats. An OLE server application provides the data, which an OLEclient application stores. The OLE libraries use the data toreconstruct an object when required.
Contents of OLE Formats
The Native data format presents the server application's internal datastructures. In the process of opening and editing an embedded object,the server application reconstructs the object from native data. Thestructure of the data is defined only by the server application.
The OwnerLink data format describes an embedded object, identifyingthe class, document name, and name of an object. Each of these data isa null-terminated string. A server application creates OwnerLink databy concatenating the three identifying strings, with a null terminatoron each, and appending a final null terminator. The following stringis an example of OwnerLink data for a portion of a bitmap saved fromWindows Paintbrush:
In the example above, Paintbrush Picture identifies the class of theobject. Because the OwnerLink data format describes an embeddedobject, the document name field is not used in OLE version 1.0. Theapplication specifies "Unused" as a place holder. The coordinates inthe object name field describe the object. Other applications can usea name such as "Figure #1234."
The ObjectLink data format describes a linked object. While itcontains the same data as the OwnerLink format, the document name andobject name fields are much more important. For example, a linkedobject that originated in Paintbrush might be described withObjectLink data as in the following:
The class name field is the same as the OwnerLink data. In thisformat, the document name identifies the actual filename of the link,and the object name identifies the portion of the file that makes upthe object. Because a linked object is not required to refer to theentire file, the object name must identify the portion of the filethat makes up the actual object. Another application may use adifferent object name, such as a range of cells in a spreadsheet, aslide number in a presentation, or a page number and line number in adocument.
Placing OLE Data on the Clipboard
When the user cuts or copies data to the clipboard, an OLE serverapplication renders the data to the clipboard. The OLE server mustrender the data in the three OLE formats, as appropriate. If theserver can support other data formats, it can also render the data inthese formats. The following list presents the data formats. Theformat that preserves the most information is listed first; subsequentformats lose fidelity.
- Application-specific data
- Native OLE format
- OwnerLink OLE format
- CF_METAFILEPICT format
- CF_DIB or CF_BITMAP format
- ObjectLink OLE format
- Any other data formats in any desired order
A server application renders data in OwnerLink format only when it canprovide an embedded object. It renders data in ObjectLink format onlywhen the server has a known filename in which the object is stored,and only when the user is copying the data to the clipboard. If theobject is new and it does not have a known filename, or if the user iscutting the data to the clipboard, the server does not provide theObjectLink data format.
The CF_BITMAP, CF_DIB, and CF_METAFILEPICT formats provide a staticgraphic representation of an object. An OLE server application shouldalways provide data in CF_METAFILEPICT format.