Avanzando con GH Freebrary

[[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.

[[duilioisola]]

No te preocupes por el tema de nomenclatura
Según ISO y Wikipedia

• AE Emiratos Arabes Unidos
• AR Argentina
• SA Arabia Saudita

Por lo demás, no conozco esta librería, pero trataré de hecharle un vistazo cuando tenga un poco de tiempo...

[[Al González]]

Empezado por duilioisola

No te preocupes por el tema de nomenclatura
Según ISO y Wikipedia

• AE Emiratos Árabes Unidos
• AR Argentina
• SA Arabia Saudita

Por lo demás, no conozco esta librería, pero trataré de echarle un vistazo cuando tenga un poco de tiempo...

Muchas gracias Duilio.

El problema viene al querer usar las siglas de idiomas bajo ese mismo esquema:

AE - Avéstico
AR - Árabe
SA - Sánscrito

Creo que la solución a este pequeño detalle será usar el código de tres letras para países y el de dos letras para idiomas, o viceversa:

Opción a) GHFMEX, GHFESP, GHFARG, GHFUSA, GHFSAU...; GHFES, GHFEN, GHFAR.

Opción b) GHFMX, GHFES, GHFAR, GHFUS, GHFSA...; GHFSPA, GHFENG, GHFARA.

(Con la suerte de que no hay códigos "RTL" y "VCL").

¿Cuál sería mejor?

[[fjcg02]]

Otras aplicaciones utilizan la siguiente nomenclatura que os adjunto.

Soporta catalán, gallego, euskera, ....

No sé si podría adaptarse esta nomenclatura sin que se "rompa" nada. Lo bueno que le veo es que la raíz común agrupa a los idiomas comunes.

Un saludo

23/07/2011 23:05 260.093 ar.po -> Arabe
23/07/2011 23:05 314.430 bg.po
23/07/2011 23:05 258.493 br.po
23/07/2011 23:05 272.391 bs.po
18/08/2011 12:18 324.575 ca.po
14/08/2011 23:05 281.714 cs.po
23/07/2011 23:05 260.832 da.po
23/07/2011 23:05 327.100 de.po
23/07/2011 23:05 304.555 el.po
23/07/2011 23:05 258.505 en_US.po
19/08/2011 23:06 325.047 es.po -> español
23/07/2011 23:05 279.051 es_AR.po -> español Argentina
23/07/2011 23:05 258.686 es_CL.po -> español Chile
11/08/2011 23:05 320.872 es_EC.po -> español Ecuador
23/07/2011 23:05 325.165 es_PY.po -> español Paraguay
23/07/2011 23:05 265.893 et.po
23/07/2011 23:05 258.444 eu.po
23/07/2011 23:05 258.447 fa.po
23/07/2011 23:05 258.232 fa_AF.po
19/08/2011 23:06 285.899 fi.po
30/07/2011 23:05 327.587 fr.po -> francés
23/07/2011 23:05 258.717 fr_BE.po -> francés Bélgica
23/07/2011 23:05 279.189 gl.po
23/07/2011 23:05 260.056 gu.po
23/07/2011 23:05 258.306 he.po
23/07/2011 23:05 258.870 hi.po
12/08/2011 23:05 282.805 hr.po
23/07/2011 23:05 322.201 hu.po
23/07/2011 23:05 282.438 id.po
03/08/2011 23:05 310.815 it.po
23/07/2011 23:05 258.264 kab.po
23/07/2011 23:05 259.050 ko.po
23/07/2011 23:05 259.743 lo.po
23/07/2011 23:05 275.245 lt.po
23/07/2011 23:05 265.252 lv.po
23/07/2011 23:05 258.615 mk.po
23/07/2011 23:05 314.744 mn.po
23/07/2011 23:05 280.887 nb.po
23/07/2011 23:05 293.334 nl.po
23/07/2011 23:05 268.053 nl_BE.po
23/07/2011 23:05 260.279 oc.po
02/08/2011 23:05 301.955 pl.po
23/07/2011 23:05 323.844 pt.po
23/07/2011 23:05 322.802 pt_BR.po
23/07/2011 23:05 278.770 ro.po
19/08/2011 23:06 340.281 ru.po
23/07/2011 23:05 258.238 si.po
23/07/2011 23:05 259.906 sk.po
23/07/2011 23:05 268.560 sl.po
23/07/2011 23:05 261.108 sq.po
23/07/2011 23:05 272.719 sr.po
23/07/2011 23:05 272.291 sr@latin.po
23/07/2011 23:05 286.970 sv.po
23/07/2011 23:05 258.486 ta.po
23/07/2011 23:05 261.118 te.po
23/07/2011 23:05 268.056 th.po
23/07/2011 23:05 258.057 tlh.po
23/07/2011 23:05 317.121 tr.po
23/07/2011 23:05 258.414 ug.po
23/07/2011 23:05 271.113 uk.po
23/07/2011 23:05 258.213 ur.po
23/07/2011 23:05 326.645 vi.po
16/08/2011 23:05 300.226 zh_CN.po
23/07/2011 23:05 258.421 zh_HK.po
23/07/2011 23:05 258.625 zh_TW.po

[[poliburro]]

Saludos AL, estaba buscándote en el mensajero para comentarte que me ha parecido muy interesante la ténica para clonar recordsets. Por ello me aboqué a buscar cómo hacerlo en ADO y encontré un método que nos permite hacerlo. Te dejo el enlace a mi blog por si gustas darle una mirada....

http://elpoli.delphiaccess.com/clona...-ado-y-delphi/

[[Al González]]

Empezado por fjcg02

Otras aplicaciones utilizan la siguiente nomenclatura que os adjunto. [...]

Gracias Javier. Como podrás notar, esas siglas siguen los estándares ISO referidos en mensajes anteriores.

Empezado por poliburro

Saludos AL, estaba buscándote en el mensajero para comentarte que me ha parecido muy interesante la ténica para clonar recordsets. Por ello me aboqué a buscar cómo hacerlo en ADO y encontré un método que nos permite hacerlo. Te dejo el enlace a mi blog por si gustas darle una mirada....

http://elpoli.delphiaccess.com/clona...-ado-y-delphi/

Gracias Edgar. Tú siempre dispuesto a enriquecer los temas.

Disculpa que no estuviera en el mensajero (sólo lo uso cuando hay que charlar con alguien ), aparte los jueves no reviso mi buzón de correo.

He leído tu artículo con interés, y me permití dejar un comentario ahí.

Saludos.

[[Al González]]

Para actualizar el hilo.

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.

Ahora sí son considerados los archivos .rels.

7. «Renombrar la unidad GHFMX [...]».

Se renombró como GHFMEX. Códigos ISO de tres letras para países y de dos letras para idiomas.

8. «[...] crear uno o varios BPL [BPL / DPK] para su instalación [...]».

Por el momento la biblioteca vendrá sin "paquetes de fábrica".

Subiré la actualización en los próximos días. Por ahora, si me echan una mano con los otros puntos...conforme puedan, claro.

Un saludo.

Al.

[RolphyReyes]

Empezado por Al González

Para actualizar el hilo.


Ahora sí son considerados los archivos .rels.


Se renombró como GHFMEX. Códigos ISO de tres letras para países y de dos letras para idiomas.


Por el momento la biblioteca vendrá sin "paquetes de fábrica".

Subiré la actualización en los próximos días. Por ahora, si me echan una mano con los otros puntos...conforme puedan, claro.

Un saludo.

Al.

Saludos.

Todo el interesado y Al, favor de revisar este hilo.

[roman]

Sería bueno que comentaras algo aquí, dado que aquí se desarrolla este hilo.

// Saludos

[[Al González]]

Muchas gracias Rolphy.

Efectivamente, el Unicode es la principal barrera a salvar cuando se quiere adaptar una biblioteca de Delphi "<2009" a Delphi ">=2009". Encuentro muy valiosas las inspecciones que has hecho, serán parte de las cuestiones a tomar en cuenta para lograr obtener nuevas versiones.

De paso mencionar que se ha creado un foro para bibliotecas de programación y dentro de él nos hicieron el invaluable favor de crear uno específico para GHF, donde podremos llevar a cabo el desarrollo de todos estos temas. Ojalá siga contando con tu apoyo y el de muchos otros colegas.

Un abrazo.

Al González.

[roman]

Empezado por roman

Sería bueno que comentaras algo aquí, dado que aquí se desarrolla este hilo.

// Saludos

Hice la petición de forma amable pero no obtuve respuesta, por lo que me veo en la penosa necesidad de borrar el enlace del mensaje del señor RolphyReyes.

Aquí no tenemos ninguna traba para enlazar a otros sitios pero sí cuando esto se hace más por publicitarlos que por ahondar en el tema que se esté tratando.

// Saludos

[[egostar]]

Empezado por roman

Hice la petición de forma amable pero no obtuve respuesta, por lo que me veo en la penosa necesidad de borrar el enlace del mensaje del señor RolphyReyes.

Aquí no tenemos ninguna traba para enlazar a otros sitios pero sí cuando esto se hace más por publicitarlos que por ahondar en el tema que se esté tratando.

// Saludos

Que tal estimado Román, en realidad no era para publicitar nada, el tema también se está tratando en delphiaccess y me parece que Alberto ha visto también el beneficio de no repetir en ambos lados lo mismo y no nos ha parecido de ninguna forma un medio de publicitar a ClubDelphi, sino todo lo contrario, como una forma de integrar ambas partes en un sólo proyecto.

Muchas gracias, Rolphy.

Vi el aviso que dejaste en Club Delphi, donde, por cierto, se te echa de menos como a casi todos los grandes amigos que tengo aquí. Pongo un enlace a mi respuesta, para no redundar: http://www.clubdelphi.com/foros/show...434#post457434

Saludos.

Al González.

Lamento pues, que se haya entendido como publicidad gratis a delphiaccess.

Saludos

[RolphyReyes]

Empezado por roman

Hice la petición de forma amable pero no obtuve respuesta, por lo que me veo en la penosa necesidad de borrar el enlace del mensaje del señor RolphyReyes.

Aquí no tenemos ninguna traba para enlazar a otros sitios pero sí cuando esto se hace más por publicitarlos que por ahondar en el tema que se esté tratando.

// Saludos

Saludos.

Sr. Román, le pido disculpa por no haber respondido a tiempo su tan cortes invitación a debatir este tema aquí también, como usted entenderá, al momento de ver su invitación estaba laborando lo cual implica que estaba escaso de tiempo en ese momento pero ahora estoy conectado desde mi casa.

El Sr. Al González esta atento, en conocimiento, de que en DelphiAccess se debate o se comenta este tema de igual manera como se realiza acá en ClubDelphi; simplemente me tome la libertad de copiar el modo de Al en hacer referencias entre foros, no lo hice con intención de dar publicidad creo que ambos foros son bastantes conocidos y no necesitan que yo, de manera particular, les haga publicidad alguna. Le reitero mi mas sincera disculpas.

Sr. Román, le comentare sobre mi progreso de la compilación del proyecto en Delphi XE.

Procedí a crear un paquete con todas las unidades, salvo GHFFirebirdSQLConnection y GHFSQLConnection, al realizar la compilación me encuentro con el siguiente error en la unidad GHFClientDataSet: [DCC Error] GHFClientDataSet.pas(139): E2268 Parameters of this type cannot have default values en los métodos:

Código Delphi [-]
Function CreateCursor (Const ABookmark :TBookmark = Nil)
          :IDSCursor;
Procedure EnableControls (Const ABookmark :TBookmark = Nil);

Indagando, encontré que Embarcadero cambio el tipo de datos de TBookmark anteriormente (<= Delphi 2007) era del tipo Pointer pero para versiones modernas (>= Delphi 2009) es del tipo TBytes. Hasta aquí todo bien porque pude realizar la compilación con Delphi 2010 (en el hilo del enlace indico mis descubrimientos) pero a partir de Delphi XE se introdujo un bugs por parte de EMBT y se corrige en Delphi XE3 (buscar el nombre del error que expuse con referencia al tipo TBytes).

¿Tienen algún WorkAround para las versiones de Delphi XE y XE2?

Gracias.