Object handlers are DLLs that can be written to handle tasks that normally are done by a server. While there can be many reasons why you would want to intercept function calls to a server, the main reason is to avoid asynchronous communication between client and server DLLs. Object handlers also can be used to optimize output to a particular device, screen, or printer. Another use of handlers is to reduce object memory and file size by using only the native data for rendering and avoiding clipboard formats.
As shown in Figure 32, when a client application calls a function in the OLE client DLL (OLECLI.DLL), the call goes through an API layer and into the matching function. For example, if a client application calls OleExecute, the OLECLI.DLL takes the function call, checks certain parameters, and transfers the call to a function pointed to by OLEOBJECTVTBL inside OLECLI.DLL (named Execute). Asynchronous messages are sent to the server application via the OLE DLLs.
Figure 32. Normal OLE function calling
However, if an object handler is invoked, the handler has a copy of the OLEOBJECTVTBL and allows redirection of the OleExecute call. This redirection enables the incoming OleExecute call to go to the handler (or, if no redirection is indicated, to OLECLI.DLL).
For a list of asynchronous functions, see the section "Handling Asynchronous Operations," in Chapter 5, "Implementing OLE into Client Applications."
In Figure 33, the OLEOBJECTVTBL has been copied to the handler. OLEOBJECT is a structure that normally points to the OLEOBJECTVTBL in the OLECLI.DLL, but OLEOBJECT has been modified to point to the new OLEOBJECTVTBL in the handler. When OleExecute is called, the call is redirected to a new DllExecute function in HANDLER.DLL. Asynchronous communication between the OLE DLLs is avoided.
Figure 33. Object handler function calling
Note The implementation of the protocols and APIs used in support of object handlers are release-specific and may not be available in future versions of OLE.