Vinculación e incrustación de objetos

OLE 1.0, lanzado en 1990, fue una evolución del concepto original de Intercambio Dinámico de Datos (DDE) que Microsoft desarrolló para versiones anteriores de Windows . Mientras que DDE se limitaba a transferir cantidades limitadas de datos entre dos aplicaciones en ejecución, OLE era capaz de mantener vínculos activos entre dos documentos o incluso incrustar un tipo de documento dentro de otro.

Los servidores y clientes OLE se comunican con las bibliotecas del sistema mediante tablas de funciones virtuales (VTBL). La VTBL consiste en una estructura de punteros a funciones que la biblioteca del sistema puede usar para comunicarse con el servidor o el cliente. Las bibliotecas del servidor y del cliente, OLESVR.DLL y OLECLI.DLL , se diseñaron originalmente para comunicarse entre sí mediante el mensaje WM_DDE_EXECUTE .

OLE 1.0 evolucionó posteriormente hasta convertirse en una arquitectura para componentes de software conocida como Component Object Model (COM), y más tarde DCOM .

Cuando un objeto OLE se copia al portapapeles o se inserta en un documento, se almacena tanto una representación visual en formatos nativos de Windows (como un mapa de bits o un metarchivo ) como los datos subyacentes en su propio formato. Esto permite que las aplicaciones muestren el objeto sin necesidad de cargar la aplicación que lo creó, y también permite editarlo si la aplicación correspondiente está instalada.

El Object Packager , un componente de OLE presente desde Windows 3.1 hasta Windows XP, permite "empaquetar" un objeto que no es OLE para que pueda integrarse en un cliente OLE.

OLE 2.0 fue la siguiente evolución de OLE, compartiendo muchos de los mismos objetivos que la versión 1.0, pero se reimplementó sobre COM en lugar de usar VTBL directamente. Las nuevas características fueron la automatización de OLE , arrastrar y soltar , activación in situ y almacenamiento estructurado . Los Monikers evolucionaron a partir de los nombres de objetos de OLE 1 y proporcionaron un sistema jerárquico de nombres de objetos y recursos similar a las URL o URI , que se inventaron de forma independiente. Windows ahora ha fusionado las dos tecnologías, admitiendo un tipo de Moniker de URL y un esquema de URL de Moniker. OLE 2.0 introdujo UUID para etiquetar objetos de API. ^{[ 2 ]}

Los controles personalizados OLE se introdujeron en 1994 como reemplazo de los controles de extensión de Visual Basic, ahora obsoletos. En lugar de actualizarlos, la nueva arquitectura se basó en OLE. En particular, cualquier contenedor que admitiera OLE 2.0 ya podía incorporar controles personalizados OLE, aunque estos controles no pueden reaccionar a eventos a menos que el contenedor lo admita. Los controles personalizados OLE generalmente se distribuyen como una biblioteca de vínculos dinámicos con la extensión .ocx. En 1996, todas las interfaces para controles (excepto IUnknown) se hicieron opcionales para reducir el tamaño de los archivos de controles y así acelerar su descarga; estos se denominaron entonces controles ActiveX .

DataObject

When implemented, enables the transfer of data, and notification of data changes. It must be implemented by objects that are to support drag-and-drop, being copied to or pasted from the clipboard, or being linked or embedded in a containing document.

ObjectWithSite

Allows the caller to inform the OLE object of its site. This functionality is also provided by OleObject, but ObjectWithSite can be used, when supported, if OleObject is not used for other matters.

OleCache

Allows visual presentations from a DataObject to be cached. This allows an embedded object to store its visual representation, thus enabling it to be displayed later without needing to start the application that was used to create the object.

Usually the stock implementation is used.

OleCache2

Provides more fine-grained control over caching.

Usually the stock implementation is used.

OleCacheControl

This interface is not called by the container, but internally by the object to allow it to receive notifications of when its DataObject is running, thereby allowing it to subscribe to notifications of data changes of that object and thus allowing it to update the cached presentation properly.

Usually the stock implementation is used.

OleDocument

Allows the OLE object to support multiple views of its data, as well as a few related functions.

OleDocumentView

A document object (an object that implements OleDocument) implements this interface for every view. It allows the caller to set the site of the object, query and set the size of the object and to show and activate it, as well as some related functions.

OleWindow

OleInPlaceActiveObject

Called by the outermost container of an object to interact with it while it's active, e.g. to process accelerator keys in the container's message queue that are meant for the contained object.

OleInPlaceObject

Called by the container to activate or deactivate the object.

IOleInPlaceObjectWindowless

A windowless object is an object that doesn't have its own window but it instead displayed in its container's window. It is used by the container to relay messages received by the container's window that are intended for the contained object. For example, if the mouse is moved over a window, Windows places a mouse move message along with the mouse coordinates in the message queue of the window. If this window contains windowless embedded objects, the message may have to be relayed to such an object if the coordinates of the mouse-pointer are over this object. For similar reasons this interface also provides access to the object's DropTarget interface.

OleLink

Allows the object to support linking, e.g. by allowing the container to set the source of a linked object.

Usually the stock implementation is used.

OleObject

Arguably the most important interface for an OLE object. For example, it allows the container to inform the object of its site, initialize the object from data, to open and close it, to query and set the size of the object, to ask for notifications on the container's AdviseSink and to execute objects defined as "verbs" on the object. These verbs often include "Open" or "Edit", but can also include other verbs. One of the verbs is defined to be the principal verb, and it is executed when the user double-clicks an object.

ViewObject

Allows an object to draw itself directly, without passing a DataObject to the container. For objects that support both DataObject and this interface, the underlying implementation is usually shared.

ViewObject2

Additionally allows the caller to query the size of the object.

ViewObjectEx

Adds support for flicker-free drawing of transparent objects, hit-testing for objects with irregular shapes and setting the size of an object.

IAdviseSink

Allows the implementer to receive notifications when the object is saved, closed, or renamed, or when its data or visual presentation changes.

IAdviseSink2

Additionally allows the implementer to receive notifications when the link source of the OLE object changes.

IAdviseSinkEx

Additionally allows the implementer to receive notifications when the view status of the OLE object changes.

IOleClientSite

This interface allows the caller to obtain information on the container and location of an object, as well requesting that the object be saved, resized, shown, hidden, et cetera.

IOleDocumentSite

Allows the caller to ask for the object on this site to be activated immediately. If this interface is implemented, IOleClientSite, IOleInPlaceSite and IAdviseSink must be implemented as well.

IOleContainer

This interface allows the caller to enumerate embedded objects in a container, or to find such objects by name. It is primarily useful if the container wishes to support links to embedded objects.

IOleWindow

IOleInPlaceUIWindow

Enables embedded objects to negotiate space for toolbars on the container's window.

IOleInPlaceFrame

Allows the caller to ask the container to insert its menu items in an empty menu that will become the cooperative menu. Also allows the caller to ask the container to show or hide this menu, to show or hide dialog boxes, and to process accelerator keys received by the contained object intended for the container.

IOleInPlaceSite

If a container implements this interface, it allows embedded objects to be activated in place, i.e. without opening in a separate window. It provides access to the container's IOleInPlaceUIWindow.

IOleInPlaceSiteEx

If a container implements this interface, it allows embedded objects to check whether they need to redraw on activation or deactivation. It also allows them to request their UI to activate.

IOleInPlaceSiteWindowless

If a container wishes to support windowless embedded objects, it needs to provide functionality to embedded objects to replace the functionality normally provided by an embedded object's window. For example this interface provides a way to access the container's window's device context, thereby enabling the embedded object to draw in the container's window.

IOleUILinkContainer

Contains the methods that the standard OLE dialog boxes that manage linked objects use to update linked objects in a container, or to query and change their sources. Used by the "Links", "Change source", "Update links" and "Object properties" dialog boxes.

IOleUILinkInfo

Additionally allows the dialog boxes to query when linked objects were last updated, and whether this was done automatically or manually.

IOleUIObjInfo

Contains the methods needed by the "Object properties" dialog box. For example if the user opens the "Object properties" dialog box and asks for the object to be converted to another type, a method on this interface is called.

IOleUndoManager

Provides a centralized undo service to both the container itself and to embedded objects. When an undoable action is performed, an IOleUndoUnit is created and added to the IOleUndoManager

IDataAdviseHolder

The methods of IDataObject that pertain to data change notifications can be implemented by calling the methods of this interface.

Usually the stock implementation is used.

IOleAdviseHolder

The methods of IOleObject that pertain to notifications can be implemented by calling the methods of this interface.

Usually the stock implementation is used.

IDropSource

Implemented by objects that can be dragged, i.e. that can be the source of a drag-and-drop operations. When implemented it allows the object to draw drag-and-drop effects, and to specify when the object is dropped, or the drag-and-drop operation is cancelled.

IDropTarget

Implemented by objects that accept dropped objects, i.e. that can be the target of drag-and-drop operations. When implemented it allows the target to specify if a dropped object will be accepted, and what happens to an object after it is dropped.

IOleCommandTarget

Can be implemented by objects (OLE objects, OLE containers, and other objects) that wish to support certain standard commands. It allows callers to query if commands are supported, and to execute commands. Commands that an object might typically wish to implement may include things like "delete", "cut", "copy", "paste", "undo", "find", "print", "save", "zoom", and so on. Currently 58 standard commands have been defined, and they include commands commonly used by office software, web browsers and similar applications.

IOleUndoUnit

Represents an action that can be undone. It contains all information necessary to undo an action. It is created by objects and containers, so that undoable actions can be added to the container's IOleUndoManager.

IOleParentUndoUnit

Allows an undo unit to contain other undo units. In essence this allows the undo unit to act as an undo stack, grouping undo units together. For example, if a macro is run, all undo-able actions performed by the macro may be grouped together in one undo unit.

IOleWindow

This interface represents a window of a container or contained object. It allows callers to obtain the handle of the window, and to toggle the context-sensitive help function. When the context-sensitive help function is turned on, typically the mouse-pointer changes to an arrow with a question mark to indicate that clicking a user interface element will result in opening a help window.