[[Al González]]

O al menos esa es la intención.

En días recientes varios y estimados compañeros de la Comunidad han mostrado vivo interés en echar un vistazo a esta biblioteca de funciones y clases; colegas como ecfisa, tiammat, fjcg02, Marc, Wilson, poliburro, egostar, Rolphy Reyes, y hago una mención especial a Neftalí, que fue uno de los primeros maestros que tuvieron la gentileza de acercarse a este trabajo hace algunos ayeres.

Resulta extraño que un rústico video publicado y explicado hace 4 años, y casi olvidado todo este tiempo, atraiga de pronto mayor interés gracias a la magia de la incrustación. Así que me permito hacer lo mismo aquí nuevamente, a fin de incentivar el aprovechamiento del componente TghDataSource:



En el tintero hay muchas ideas y planteamientos. Me permito enumerar ocho de ellos para someterlos a su opinión.

1. Pienso que adaptar TghDataSource a nuevas versiones de Delphi podría ser una de las próximas tareas a realizar, dado el interés que despiertan las características de este componente.

2. Las otras clases, aunque no son tan "universales" como el DataSource, también tienen lo suyo y conviene examinar cuáles valdría la pena ir adaptando también.

3. Pero las funciones sueltas, que no son pocas, también algún valor les han de encontrar quienes usan versiones más modernas que la 7.

En mi caso, dispongo de Delphi 2007 Professional y XE2 Enterprise para ayudar en la adaptación de GH Freebrary a versiones posteriores a la 7. Por cierto,

4. ¿habrá necesidad de considerar a alguna versión anterior también (1..6)?

5. Creo que es menester cambiar un poco la clase TghOpenXMLSpreadsheetBook para que no obvie el uso del archivo workbook.xml.rels al localizar una hoja de cálculo por su nombre. Incluso también podría usar ese archivo para encontrar el de las cadenas de caracteres, sharedStrings.xml. Admito que me falta mucho por aprender del estándar OpenXML, al grado de que recientemente agregué un pequeño comentario con prejuicio hacia LibreOffice en el código fuente.

Por otro lado, han comenzado a llegar valiosas sugerencias y observaciones:

De fjcg02 y mía:

6. Revisar qué versión de MSXML debe usar TghXMLDoc, agregando quizá una variable de clase o parámetro con el que el programador pueda indicar la versión a utilizar. Incluso puede ser que, de forma predeterminada, la clase determine esto mediante una consulta en el Registro de Windows. Actualmente el código del constructor está así:

Código Delphi [-]
  Constructor TghXMLDoc.Create (Const AContent :String = '');
  Begin
    Content := CreateOLEObject ('MSXML2.DOMDocument.4.0');
    Content.Async := False;

    If (AContent <> '') And Not Load (AContent) Then
      ghRaise ('Invalid content or file for XML document.');
  End;

De Rolphy Reyes:

7. «Renombrar la unidad GHFMX debido a que da la impresión de estar relacionado con la nueva tecnología de EMBT de nombre FireMonkey».

8. «(Esta puede estar sujeta a discusión) Crear uno o varios BPL para su instalación, normalmente toda librería [biblioteca] de componentes tiene(n) su(s) propio(s) paquete(s) así se facilitara el trabajo de migración (eso creo)».

-------------------------

Ahora, me permito responder a los anteriores temas, invitando a quienes tengan interés por GH Freebrary a que participen de la misma manera conforme dispongan de algo de su valioso tiempo.

Puntos 1, 2 y 3: Como autor y al mismo tiempo usuario de este recurso, todo el material que contiene me resulta valioso para hacer que esté disponible y debidamente adaptado en las más recientes y aceptadas versiones de Delphi. Claro que unas cosas pueden ser más valiosas que otras y depende bastante del proyecto en el que se quieran emplear.

Punto 4: Pienso que sólo Delphi 5 y 6 deberían ser consideradas como potenciales versiones a atender, y solamente adaptando un reducido grupo de clases y funciones a dichas versiones.

Punto 5: Eso lo debo arreglar antes de que traiga consecuencias "graves".

Punto 6: Algo a analizar y para lo cual podríamos partir de este documento que hoy encontré: http://blogs.msdn.com/b/xmlteam/arch...-explorer.aspx

Punto 7. Todos los archivos de código de GH Freebrary comienzan con las iniciales "GHF" y "MX" es el código ISO de dos letras asignado al país México. En la biblioteca existen dos unidades más cuyo nombre se compone de elementos similares: GHFEN (utilidades del idioma inglés) y GHFES (utilidades para España y del idioma español). Las tres unidades son muy pequeñas todavía, pero nos dan pauta para agregarles con el paso del tiempo más funciones, clases o constantes relacionadas con México (MX), el idioma inglés (EN), y España y el idioma español (ES), respectivamente. Esto además establece una propuesta de cómo tendrían que ser nombradas las nuevas unidades que lleguen a crearse para aspectos de otros idiomas y países.

Al manejar siglas es frecuente que ocurran este tipo de coincidencias. Renombrar la unidad significaría cambiar la regla anteriormente descrita y terminaríamos renombrando al menos dos unidades más. En mi opinión el uso de la sigla FMX para FireMonkey, con la consecuente impresión que causa al ver GHFMX, no tiene el suficiente peso para obligarnos a hacer ese cambio. Pero bueno, debemos aprovechar que los foros le permiten a un grupo de personas ponerse de acuerdo, y construir las mejores soluciones con base en las opiniones y argumentos de cada participante.

En descargo y analizando mis propias palabras, creo que vamos a toparnos con un verdadero problema cuando nos toque crear la unidad GHFAR (¿Argentina o idioma árabe?). ¡Puf, que metida de pata!

Punto 8. Con el tiempo he llegado a la conclusión (quizá estoy equivocado) de que los paquetes de Delphi tienden a volverse problemáticos, debido a las inevitables dependencias que guardan unos con otros. En viejas versiones de GH Freebrary (Interfaz GH, Magia Data) incluía un .dpk "de fábrica" para facilitar su registro en la paleta de componentes, y eso es ciertamente lo que hacen casi todos los autores de bibliotecas. Pero como usuario de Delphi, y después de varias desagradables experiencias por conflictos entre paquetes a raíz de los famosos requires, he optado por no crearle problemas al usuario de los componentes gh "heredándole" paquetes de fábrica que eventualmente va a tener que editar a fin de instalar el componente que desea usar realmente.

He preferido entregar una unidad "XXX_Reg" para cada uno de los componentes, y así el desarrollador decide cuáles instalar y cuáles no, dejando a su criterio el agregar estas unidades a un paquete existente (que podría ser DclUsr) o crear para ello uno nuevo. Esto lo indico en las instrucciones de instalación. Además, esto crea menos dependencias entre las propias unidades de la biblioteca, facilitando con ello la transición por partes a otras versiones de Delphi.

Reitero la invitación para que ofrezcan sus consejos, críticas y opiniones sobre los temas antes planteados. Y si quieren poner algún otro sobre la mesa, adelante, hacerlo con toda libertad ampliando esta lista de temas, continuando con el número 9. Sé que mi trabajo no es el mejor del mundo, pero he ahí la razón para dejarlo abierto al perfeccionamiento mediante su ayuda.

Saludos y gracias de antemano.

Al González.

P.D. Rolphy, Eliseo: Para mí ya es algo tarde, pero retroalimentaré ese otro hilo pronto. Un saludo.