Ver almacenamiento en caché

Una aplicación contenedora debe poder obtener una presentación de un objeto con el fin de mostrarlo o imprimirlo para los usuarios cuando el documento está abierto, pero la aplicación de servidor del objeto no se está ejecutando o no está instalada en el equipo del usuario. Sin embargo, para suponer que los servidores de todos los objetos que podrían encontrarse en un documento se instalan en el equipo de cada usuario y siempre se pueden ejecutar a petición no es realista. El controlador de objetos predeterminado, que está disponible en todo momento, resuelve este dilema almacenando en caché las presentaciones de objetos en el almacenamiento del documento y manipulando estas presentaciones en cualquier plataforma, independientemente de la disponibilidad del servidor de objetos en cualquier instalación concreta del contenedor.

Los contenedores pueden mantener presentaciones de dibujo para uno o varios dispositivos de destino específicos además del necesario para mantener el objeto en pantalla. Además, si se pasa el objeto de una plataforma a otra, OLE convierte automáticamente los formatos de datos del objeto en los admitidos en la nueva plataforma. Por ejemplo, si mueve un objeto de Windows a Macintosh, OLE convertirá sus presentaciones de metarchivo a formatos PICT.

Para presentar una representación precisa de un objeto incrustado al usuario, la aplicación contenedora del objeto inicia un diálogo con el controlador de objetos, solicitando datos e instrucciones de dibujo. Para poder satisfacer las solicitudes del contenedor, el controlador debe implementar las interfaces IDataObject, IViewObject2 e IOleCache .

IDataObject permite que una aplicación contenedora OLE obtenga datos de y envíe datos a sus objetos incrustados o vinculados. Cuando los datos cambian en un objeto, esta interfaz proporciona una manera de que el objeto haga que sus nuevos datos estén disponibles para su contenedor y proporcione al contenedor una manera de actualizar los datos en su copia del objeto. (Para obtener una explicación de la transferencia de datos en general, vea el capítulo 4, Transferencia de datos).

La interfaz IViewObject2 es muy similar a la interfaz IDataObject , salvo que pide a un objeto que se dibuje en un contexto de dispositivo, como una pantalla, una impresora o un metarchivo, en lugar de mover o copiar sus datos en la memoria o en algún otro medio de transferencia. El propósito de la interfaz es permitir que un contenedor OLE obtenga representaciones pictoriales alternativas de sus objetos incrustados, cuyos datos ya tiene, evitando así la sobrecarga de tener que transferir instancias completamente nuevas de los mismos objetos de datos simplemente para obtener nuevas instrucciones de dibujo. En su lugar, la interfaz IViewObject2permite al contenedor pedir a un objeto que proporcione una representación pictorial de sí misma dibujando en un contexto de dispositivo especificado por el contenedor.

Al llamar a la interfaz IViewObject2 , una aplicación contenedora también puede especificar que el objeto se dibuje en un dispositivo de destino diferente al del que realmente se representará. Esto permite que el contenedor, según sea necesario, genere diferentes representaciones a partir de un único objeto. Por ejemplo, el autor de la llamada podría pedir al objeto que se componga para una impresora aunque el dibujo resultante se represente en pantalla. El resultado, por supuesto, sería una vista previa impresa del objeto .

La interfaz IViewObject2también proporciona métodos que permiten a los contenedores registrarse para las notificaciones de cambio de vista. Al igual que con los datos y avisos OLE, una conexión de aviso de vista permite a un contenedor actualizar sus representaciones de un objeto en su propia comodidad en lugar de en respuesta a una llamada desde el objeto. Por ejemplo, si una nueva versión de la aplicación de servidor de un objeto fuera ofrecer vistas adicionales de los mismos datos, el controlador predeterminado del objeto llamaría a la implementación de cada contenedor de IAdviseSink::OnViewChange para informarles de que las nuevas presentaciones estaban disponibles. El contenedor recuperaría esta información del receptor de aviso solo cuando sea necesario.

Dado que los contextos de dispositivo Windows solo tienen significado dentro de un único proceso, no se pueden pasar punteros IViewObject2 a través de los límites del proceso. Como resultado, los servidores locales y remotos OLE no tienen necesidad de implementar la interfaz, lo que no funcionaría correctamente incluso si lo hicieran. Solo los controladores de objetos y los servidores en proceso implementan la interfaz IViewObject2. OLE proporciona una implementación predeterminada, que puede usar en sus propios servidores OLE en proceso y controladores de objetos simplemente agregando el controlador predeterminado OLE. O bien, puede escribir su propia implementación de IViewObject2.

Un objeto implementa la interfaz IOleCache para que el controlador sepa qué funcionalidades debe almacenar en caché. El controlador de objetos también posee la memoria caché y garantiza que se mantiene actualizado. A medida que el objeto incrustado entra en estado en ejecución, el controlador configura las conexiones de asesoramiento adecuadas en el objeto de servidor, y actúa como receptor. Las implementaciones de la interfaz IDataObject e IViewObject2funcionan fuera de los datos almacenados en caché en el lado cliente. La implementación del controlador de IViewObject2es responsable de determinar qué formatos de datos almacenar en caché para satisfacer las solicitudes de dibujo del cliente. La implementación del controlador de IDataObject es responsable de obtener datos en varios formatos, etc., entre la memoria y la instancia IStorage subyacente del objeto incrustado. Los controladores personalizados pueden usar estas implementaciones mediante la agregación en el controlador predeterminado.

Temas relacionados

Documentos compuestos