Most of the object-creation functions in the client DLL work in the same way when they are renamed and used by object-handler DLLs. However, as described in the following sections, the DefCreateFromClip (renamed from OleCreateFromClip) and DefLoadFromStream (renamed from OleLoadFromStream) functions work differently.
6.4.6.1 DefCreateFromClip and DllCreateFromClip
When the client DLL calls the DllCreateFromClip function, it includes the objtype parameter that is not specified in the original call to the OleCreateFromClip function. This parameter specifies whether the object being created is an embedded object or a link to an object; its value can be either OT_LINK or OT_EMBEDDED.
The following syntax block shows the objtype parameter when an object handler uses the DefCreateFromClip function. The DllCreateFromClip function has exactly the same syntax as DefCreateFromClip.
For a full description of all the parameters, see the OleCreateFromClip function in Chapter 9, "The OLE Client DLL."
OLESTATUS DefCreateFromClip(lpszProtocol, lpclient,
lhclientdoc, pszObjname,
lplpobject, renderopt, cfFormat,
objtype);
LPSTR lpszProtocol; // pointer to string for
// protocol name
LPOLECLIENT lpclient; // pointer to client structure
LHCLIENTDOC lhclientdoc; // long handle to client
// document
LPSTR lpszObjname; // string for object name
LPOLEOBJECT FAR * lplpObject; // pointer to pointer to
// object
OLEOPT_RENDER renderopt; // rendering options
OLECLIPFORMAT cfFormat; // clipboard format
LONG objtype; // OT_LINKED or OT_EMBEDDED
If DllCreateFromClip calls DefCreateFromClip, DllCreateFromClip should pass it the objtype parameter along with the other parameters from the version of DefCreateFromClip that was exported by the client DLL.
DllCreateFromClip can modify some of these parameters before passing them back to DefCreateFromClip. For example, the object handler could specify a different value for the renderopt parameter when it calls DefCreateFromClip. If the client calls DefCreateFromClip with olerender_draw for renderopt and the handler performs the drawing with Native data, the handler could change olerender_draw to olerender_none if the handler performs the drawing with native data.
If the client DLL calls DefCreateFromClip with olerender_draw for renderopt (and the handler calls the GetData function and performs the drawing based on a class-specific format), the handler could change olerender_draw to olerender_format. If the handler needed a different rendering format than that specified by the client application, the object handler could also change the value of the cfFormat parameter in the call to DefCreateFromClip.
If an object handler uses native data to render an embedded object, the handler can call the client DLL and specify olerender_none. If a handler uses native data to render a linked object, it can use olerender_format and specify native data. When the handler's Draw function is called, the handler calls the GetData function, specifying native data, to do the rendering. If a handler uses a private data format, the procedure is the same—except that the private format is specified with the olerender_format option and with the GetData function.
6.4.6.2 DefLoadFromStream and DllLoadFromStream
When the client DLL calls the DllLoadFromStream function, it includes three parameters that are not specified in the original call to the OleLoadFromStream function. One of the additional parameters is objtype, as previously described for DefCreateFromClip and DllCreateFromClip. The other two are aClass, which is an atom containing the class name for the object, and cfFormat, which specifies a private clipboard format that the object handler can use for rendering the object.
The following syntax block shows the objtype, aClass, and cfFormat parameters when an object handler uses the DefLoadFromStream function. The DllLoadFromStream function has exactly the same syntax as DefLoadFromStream.
For a full description of all the parameters, see the OleLoadFromStream function in Chapter 9, "The OLE Client DLL."
OLESTATUS DefLoadFromStream(lpstream, lpszProtocol,
lpclient, lhclientdoc,
pszObjname, lplpobject, objtype,
aClass, cfFormat);
LPOLESTREAM lpstream; // pointer to stream for object
LPSTR lpszProtocol; // pointer to string for
// protocol name
LPOLECLIENT lpclient; // pointer to client structure
LHCLIENTDOC lhclientdoc; // long handle to client
// document
LPSTR lpszObjname; // string for object name
LPOLEOBJECT FAR * lplpobject;// pointer to pointer to object
LONG objtype; // OT_LINKED or OT_EMBEDDED
ATOM aClass; // atom containing object's
// class name
OLECLIPFORMAT cfFormat; // private data format for
// rendering
If DllLoadFromStream calls DefLoadFromStream, DllLoadFromStream should pass it the three additional parameters along with the other parameters from the version of DefLoadFromStream that was exported by the client DLL. DllLoadFromStream can modify some of these parameters before passing them back to DefLoadFromStream.
For example, the object handler could modify the value of the cfFormat parameter to specify a private data format it would use to render the object.
When the client application calls the object handler with DefLoadFromStream, the handler uses the Get function from the OLESTREAMVTBL structure to obtain the data for the object.