Solicito consejo para generar un documento totalmente dinámico

[rolandoj]

Hola a todos,

Agradezco me aconsejen como para resolver el siguiente problema:

Debo imprimir un documento totalmente dinámico, a partir de una lista de campos y de formatos introducidos por usuarios. Esto es esencialmente la misma idea de la generación de páginas Web dinámicas con TPageProducer; o sea:

Existe un registro con los valores actuales de n campos; pero, la posición y el orden en que se van a imprimir no es conocida de antemano. Para ello, el usuario haría modelos de documentos, parametrizados mediante marcadores con el nombre de un campo, indicando la posición de despliegue de cada campo. Estos modelos deben soportar un formateo básico (alineación justificada, centrada, etc; varios tipos de fuentes, y cosas similares).

El software debe hacer un parser de ese documento, encontrar las posiciones de los campos y reemplazarlos por los valores actuales. El resultado es el documento a imprimir.

La lógica es clara y facil de codificar; pero, al momento de imprimir, que técnología me brinda el mejor soporte ?

Mis dos opciones básicas son :

A. Que un componente Memo de un reporteador imprima el texto formateado. En ese caso necesito un componente de impresión de Memo que soporte un texto formateado con las especificaciones dadas. Normalmente uso QuickReport; pero el TQRMemo standard no soporta las características y el TQRRichText solo algunas, no produciría un documento de calidad. Alguién conoce componentes que lo hagan ?, quizás en otro reporteador ?

B. Generar directamente un archivo en PDF o Word, o algo similar, y mandar a imprimir el archivo. Que componente podría usar ?.

Nota 1: Descarten la automatización OLE. Serviría; pero, he detectado problemas de compatibilidad.

Nota 2: Debe funcionar con Delphi 2007, o con Delphi 4 (preferiblemente)

[Neftali [Germán.Estévez]]

Además de las opciones que comentas, creo que te has olvidado de la más "rapida" o al menos es la que primero se me ocurriría a mí. La de un componente que permita generar reportes en ejecución.
En el caso de QR, si no recuerdo mal, existía QRDesign; Aunque en su momento me suena haber leído sobre otros similares. Es un pequeño diseñador que pueden usar los usuarios finales. Con un poco de práctica se pueden generar y personalizar sus listados. Se trata de arrastrar los campos donde quieran, cambiar los tipos de letra y poco más.

La segunda opción, es utilizar por ejemplo Word o Writer (OpenOffice), generar la plantilla en Word/Writer (como para realizar una Combinación de Correspondencia o MailMerge) y luego desde programa generar los datos y realizar por código (automatización) esa combinación. Tienes que escribir más código, la automatización no es sencilla y puedes tener problemas de versiones (no con Delphi, sino con las versiones de Word -con Writer no lo he probado-).

Por último puedes trabajar directamente con TRichEdit (o similar), sin el Reporteador, puesto que TRichEdit ya posee el método de Imprimir (bastante básico, pero puedes probar si te es suficiente). Que el usuario "diseñe" el listado sobre el RichEdit con referencias a donde quieres los campos (tipo <<NOMBRE>>, <<DIRECCION>>,...) y luego tú por programa haces las sustituciones y lanzas la impresión.

Espero no haberte liado más de lo que estabas.

Un saludo.

[rolandoj]

Hola Neftali,

Muchas gracias por el apoyo. Veo que entendistes perfectamente lo que estoy buscando. Te comento lo siguiente:

1. Respecto a lo que dices de problemas con las versiones de Word, etc, y no con Delphi, estoy totalmente de acuerdo. De hecho, cuando dije que descartaba la automatización OLE fué precisamente porque en un proyecto anterior implementé así un caso similar. Funcionó muy bien; pero después se armó un problema grave cuando salió la nueva versión de Office.

2. Lo que dices del TRichEdit, conceptualmente es exactamente lo que quiero; el problema es que le falta cierta capacidad de formateo y por ello los documentos no salen muy bien presentados.

3. El QRDesign que mencionas no es un componente standard de QuickReport. Voy a investigar sobre él

[Jab]

¿Por qué no usas el FreeReport? Funciona para Delphi 4 y pueden configurar sus propios informes y documentos.
Permite exportar a Word para luego su manipulación.

Para PDF sino encuentras componente (el Quickreport permite exportar a PDF pero a partir de las versión 4) puedes usar el PDFCreator, aplicación gratuita que te instala una impresora PDF que pueden usar.

Esto son alternativas.

El QRDesign es como el FreeReport, pero mientras que el primero debes pagar por usarlo, el FreeReport es gratuito y te permite modificar el código fuente para mejorarlo o eliminar lo que no necesites.

Hay traducciones en varios idiomas.
Saludos.

[Neftali [Germán.Estévez]]

Empezado por rolandoj

2. Lo que dices del TRichEdit, conceptualmente es exactamente lo que quiero; el problema es que le falta cierta capacidad de formateo y por ello los documentos no salen muy bien presentados.

3. El QRDesign que mencionas no es un componente standard de QuickReport. Voy a investigar sobre él

Sé que hay algun componente de RichEdit que permite más cosas que el Estandard, sería cuestión de ver si encuentras uno que se ajuste a lo que necesitas.

El QRDesign es aparte; lo que ya no se si hay alguno más similar.

Otra opción, tal y como dice Jab, es buscar otro generador de reportes que posea ese módulo para que el usuario pueda crearse los suyos propios, sin necesidad de añadidos.
En mi caso no conozco ninguno, pero si FreeReport lo posee, deberías revisarlo.

Ya dirás cómo te va y que opción has escogido finalmente.

Un saludo.

[rolandoj]

Hola,

Gracias a todos por la información.

El QRdesign es un componente pago, así que debo investigarlo con cuidado antes de proceder a una compra.

El PDFCreator lo usamos actualmente para generar la salida en PDF; pero, eso asume que la salida ya está formateada. No conozco si también pued facilitar armar un documento PDF, ponerle marcadores para campo y reemplazarlos a tiempo de ejecución. Investigaré eso.

El freereport no lo conozco; pero, por la descripción parece una opción interesante; especialmente porque me permite seguir con Delphi 4 y honestamente no quisiera sacrificar Delphi 4 porque su IDE es mucho mejor que el del 2007. También lo miraré.

La opción que más me llama la atención es la posibilidad de un TRichEdit extendido; ya que el standard tiene casi todo lo que se necesita y la codificación es facil. Pienso que, de conseguir uno mejorado, el esfuerzo de implementación sería mucho menor en comparación a las otras alternativas.

El día lo tengo complicado; pero, trataré de investigar hoy mismo.

De todas formas, estaré pendiente del fory y de antemano agradezco igualmente cualquier sugerencia adicional.

[[Al González]]

Hola Rolando.

He leído este hilo desde hace varios días, pero me queda la duda (y estoy seguro de que no soy el único) sobre:

Empezado por rolandoj

[...] cuando dije que descartaba la automatización OLE fué precisamente porque en un proyecto anterior implementé así un caso similar. Funcionó muy bien; pero después se armó un problema grave cuando salió la nueva versión de Office.

¿En qué consistió ese problema? ¿De qué versión de Office hablas? ¿Podrías explayar al respecto? Gracias.

Al González.

[rolandoj]

Hola,

Gracias por interesarte.

Se trataba de una aplicación hecha con Delphi 5. La automatización la habíamos hecho con Excel para generar un reporte, que por cierto era bastante complejo. Funcionó bien con versiones de Office 97 hasta Office 2003

El caso fué cuando la empresa cliente pasó a Office 2007. La conexión OLÉ fallaba desde el arranqué. Investigamos un tiempo y, según lo que leímos en el propio sitio de Microsoft, el problema era que había que inicializar una variable a la cual Office accedía vía .NET; pero, no encontramos manera de acceder desde Delphi 5. En ese entonces buscamos algún componente que lo hiciera; pero, no hallamos nada.

Se planteó actualizar Delphi y/o recodificar en específico para Office 2007, ya que ni siquiera encontramos un componente que nos permtiera escribir un archivo Excel sin usar OLE.

Sin embargo, esa funcionalidad se perdió porque la empresa consideró que las alternativas no justificaban el esfuerzo y el costo. Al usuario principal le tocó hacer períodicamente el reporte a partir de un copy & paste desde nuestro aplicativo

[rolandoj]

Hola a todos,

En este tema ya nos habíamos resignado a que no se puede; pero, en la empresa me pidieron que hiciera un nuevo intento.

He estado investigando y desarrollando código propio. Algo avanzamos; pero, seguimos estancados. Por si le sirve a alguién, o puedo aportar algo, comento mis intentos con Delphi 4:

Hay 4 versiones principales de RTF : La 1.0, la 2.0, la 3.0 y la 4.1

La implementación de TRichEdit en Delphi 4 y Delphi 2007 directamente usa solo la versión 1.0 de RTF, la cual no soporta la alineación justificada. Ahora bien, al parecer, a nivel del propio Windows, cuando están instaladas las versiones 2 o 3, una llamada a la 1, es redirigida para usar la versión 2 o 3. Alguién podría confirmarlo ?. Es una deducción mía basada en ciertos indicios; no una certeza.

Uno de ellos es el hecho de que si se envía al control TRichEdit el mensaje de alineación justificada (propio de las versiones más nuevas), Windows lo procesa aparentemente bien. Se visualiza inmediatamente la alineación y cuando se guarda, el archivo lo guarda correctamente. El mismo comportamiento correcto ocurre si se pega al control un texto que se ha justificado en Word u otro producto similar.

Sin embargo, hasta ahí llegan las buenas noticias. Si se trata de visualizar de nuevo el archivo, cargandolo al control RichEdit, se pierde la alineación justificada.

Alguién puede preguntar aquí como sé entonces que el archivo se guardó bien. La respuesta es porque si se abre desde Word o desde Open Office, ahí sí se visualiza correctamente.

Sin embargo, si se abre con WordPad, presenta el mismo problema que en Delphi : Adios a la alineación justificada.

Lo anterior indica que lo más probable es que exista un error, a nivel del propio control RichEdit de Windows, cuando se esté cargando información al control. Si es así, creo que ya no hay más nada que podamos hacer para arreglar el problema por ese lado. Alguién puede confirmar esto ?.

La solución que quedaría sería usar la versión 4.1. Hay dos diferencias importantes con las anteriores : El nombre de la librería y el nombre de la clase. Probé redefinir CreateParams para que usara la librería y la clase de la versión 4.1; pero, en algún momento posterior empiezan a aparecer errores. Supongo que hay algunas otras cosas que deben ajustarse; pero, no he encontrado nada al respecto. Alguién puede aportar algo ?