Extender el sistema de informes en VFP 9.0. Tiempo de ejecución. Parte 1/3

Autor: Doug Hennig (http://www.stonefield.com)
Traducido por: Ana María Bisbé York

---

(Sesión Extending the VFP 9 Reporting System, Part I: Run-Time presentada por el autor en la Conferencia DevEssentials Kansas, 2004)

Resumen

Además de la extensibilidad en tiempos de diseño que fue discutida en la primera parte de este documento (ver), VFP 9 proporciona también la posibilidad de extender el comportamiento de los informes aun cuando están siendo ejecutados. En este documento aprenderá sobre el concepto del listener incorporado en VFP 9, verá cómo recibe eventos cuando está siendo ejecutado un informe y cómo puede crear sus propios listeners para proporcionar diferentes tipos de salidas además de las tradicionales pantalla e impresora.

Introducción

Uno de los mayores cambios en VFP 9.0 es la increíble mejoría hecha en el sistema de informes. Existen varios aspectos para esto, uno de los cuales expondremos en este documento: la capacidad de extender el Diseñador de informes en tiempo de ejecución

El equipo de desarrollo de VFP tuvo varios objetivos en mente al trabajar en las mejoras en tiempo de ejecución, entre ellos:

• Obtener más tipos de salidas, además de pantalla e impresora.
• Utilizar GDI+ para las salidas de informes. Esto proporciona mejoras significativas, mejor dibujado, una escala más suave de subida y bajada de imágenes y fuentes, y capacidades adicionales como son rotación de texto.
• Proporciona un sistema de informes más flexible y extensible.

VFP 9 incluye ambos motores de informe el viejo y el nuevo, así que puede ejecutar los informes en el motor que desee. Sin embargo, una vez que vea los beneficios del nuevo motor de informes, seguramente no querrá volver al viejo estilo.

Arquitectura del motor de informes.

Antes de VFP 9, el motor de informes era monolítico, controlaba todo y salvo algunas excepciones (funciones definidas por el usuario, expresiones para OnEntry y OnExit de las bandas, etc.), no podíamos interactuar con el informe durante su ejecución.

El nuevo motor de informe de VFP 9 divide la responsabilidad entre el motor de informes, que ahora controla la manipulación de datos y posición de los objetos y un objeto nuevo conocido como report listener, el que controla el dibujado y la salida. Dado que los report listeners son clases, podemos ahora interactuar con el proceso de informes de formas que antes no soñamos.

Los report listeners realizan la salida de dos formas: El modo "una página cada vez" ("Page-at-a-time") dibuja una página y luego la saca. Esto es utilizado típicamente para salidas por impresora.

En el modo "todas las páginas a la vez" ("all-pages-at-once") el report listener configura todas las páginas y las almacena en memoria. Luego las saca según la demanda. Eso es utilizado fundamentalmente en presentación preliminar.

Nueva sintaxis de informes

VFP 9 admite la ejecución de informes utilizando el viejo motor de informes, simplemente utilice el comando REPORT como hacía antes (aunque como veremos en un momento, puede utilizar un comando nuevo para sobrescribir el comportamiento de REPORT). Para obtener un comportamiento del estilo nuevo, utilice la cláusula OBJECT del comando REPORTS. Esta cláusula OBJECT admite dos formas para su uso: especificar un report listener y especificar un tipo de informe. Microsoft se refiere a esto como "salida asistida por objetos"
Un report listener es un objeto que proporciona el nuevo comportamiento para informes. Los report listeners se basan en una nueva clase base en VFP 9, ReportListener. Veremos esta clase con más detalle luego. Para decirle a VFP que utilice un listener específico para un informe, instancie la clase listener y luego especifique el nombre de objeto de la cláusula OBJECT del comando REPORT. He aquí un ejemplo.

loListener = createobject('MyReportListener')
report form MyReport object loListener 

Si no ha instanciado un listener manualmente, puede decirle a VFP que lo haga automáticamente especificando el tipo de informe.
report form MyReport object type 1

Los tipos definidos son: 0 para salida por impresora, 1 para presentación preliminar, 2 para modo "una página cada vez" pero no por impresora, 3 para "todas las páginas a la vez"; pero no invoca la presentación preliminar, 4 para salida XML, 5 para salida HTML. Se pueden definir otros tipos de salidas.

Al ejecutar un informe de esta forma, es invocada la aplicación especificada en la nueva variable del sistema _REPORTOUTPUT (de forma predeterminada ReportOutput.APP de la carpeta raíz de VFP). Esta aplicación determina qué clase listener debe instanciar para un tipo especificado. Esto se hace mirando el tipo de listener en una tabla de registro de listener, más adelante veremos este aspecto en detalles. Si encuentra la clase deseada, instancia la clase y da una referencia al objeto listener al motor de informe. De esta manera, utilizando OBJECT TYPE un tipo en el comando REPORT es esencialmente lo mismo que:

loListener = .NULL.
do (_ReportOutput) with SomeType, loListener
report form MyReport object loListener 

Probablemente piense "Pero si tengo montones de informes en mi aplicación. ¿Tendré que modificar cada comando REPORT por toda mi aplicación?" Afortunadamente, existe una forma muy sencilla: SET REPORTBEHAVIOR 90 establece la salida asistida por objetos como predeterminada. Esto significa que el comando REPORT se comporta como si hubiera especificado OBJECT TYPE 0 cuando utiliza la cláusula TO PRINT u OBJECT TYPE 1, cuando utiliza la cláusula PREVIEW. Por su parte, SET REPORTBEHAVIOR 80 revierte a VFP 80 y al comportamiento anterior. Si la mayoría de los informes de su aplicación trabajan bien con salida asistida por objetos, utilice SET REPORTBEHAVIOR 90 en el inicio de la aplicación. Debido a que existen diferencias en cuanto al dibujado y la configuración entre los dos estilos, algunos informes pueden necesitar unos retoques para que trabajen adecuadamente con el nuevo estilo. Entonces o bien, los retoca o bien utiliza SET REPORTBEHAVIOR 80 para esos informes.

La aplicación ReportOutput.APP es ante todo una fábrica de objetos, instancia el listener apropiado para un informe. Además, incluye algunos listeners que proporcionan salida XML y HTML. Sin embargo, debido a que es una aplicación Xbase puede sustituirla por su propia aplicación, estableciendo el valor correspondiente en _REPORTOUTPUT.

Otra variable de sistema, nueva es _REPORTPREVIEW y especifica el nombre de una aplicación Xbase utilizada como ventana para los informes. De forma predeterminada, esta variable apunta a ReportPreview.APP en la carpeta raíz de VFP; pero se puede sustituir por una aplicación propia si se desea. Por ejemplo, puede querer un formulario que proporcione un lista de informes a la izquierda y un área de vista preliminar a la derecha. Cuando el usuario hace doble clic en un informe, se muestra la vista preliminar en su área. La posibilidad de usar una aplicación Xbase como ventana preliminar nos proporciona casi control ilimitado sobre la apariencia y comportamiento de la presentación preliminar. Este documento no discute la aplicación ReportPreview.APP ni los requerimientos para sustituirla.