Rolphy:
Agregué tus valiosas observaciones junto con otros seis planteamientos en
este nuevo hilo, en Club Delphi (puntos 7 y 8). De todas formas pego aquí mis respuestas, adelantándote que sí vamos a tener que renombrar esa unidad, pero no debido a la sub-sigla FMX, sino a una pifia de mi parte en cuestión de siglas de países e idiomas.
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.
Eliseo:
No sé por qué daba por hecho que tenías Delphi 7. Acabo de revisar la encuesta de octubre pasado, y ya recuerdo que tienes las versiones 6, Turbo Delphi 2006 y las XEs.
El error que reportas es una de las muchas y normales cuestiones de incompatibilidad entre versiones que vamos a tener que resolver. Echando un vistazo rápido en la VCL de Delphi 2007, encontré que la causa concreta de ésta es que Borland, en alguna versión posterior a la 7, cambió la herencia de la clase TFieldList (el tipo de DataSet.FieldList), de tal manera que ya no desciende de TStrings, sino de TWideStrings.
El método TghObjList.AddItems actual (para delphi 7) puede recibir una lista TList o una lista TStrings, por lo que tendríamos que definirle otra sobrecarga de AddItems que admita un TWideStrings para ayudar a que la función ghEnumFields sea compatible con nuevas versiones. Sin embargo, ninguno de los componentes usa dicha función. El compilador marca el error porque uno o más de los componentes (uno de ellos es TghClientDataSet) usan otros elementos de la unidad GHFUtils. Así que la función podría comentarse para permitir al compilador continuar, pero de antemano te digo que saldrán más cuestiones de compatibilidad entre versiones que habrá que arreglar. Todo esto vendría quedando en el punto 2 del hilo de ocho temas que referí anteriormente.
Migrar una biblioteca de una versión a otra de Delphi es uno de los trabajos más laboriosos, pero de los que más satisfacciones surgen.
Viéndolo desde un punto de vista colectivo, ¿consideran que valdría la pena intentar ahora una versión para Turbo Delphi 2006 o concentrar la mayor parte del esfuerzo en crear una versión para Delphis un poco más actuales y utilizados como XE2? Lo ideal es que exista una versión para todos del 7 en adelante, pero dados los escasos recursos de que disponemos, quizá debamos permitir que el peso del interés comunitario lo determine.
Invito a todos a que sigamos el hilo que inicié ayer en Club Delphi (
http://www.clubdelph...ead.php?t=82395), o si prefieren que empecemos uno igual en DelphiAccess. Aunque de antemano preferiría que no tuviéramos que "duplicar" trabajo, ya que, como saben, pocas veces basta con
copiar y pegar.
Un abrazo.
Al González.
4056_eeb53b7ac1730430d41f2292e1b56502363620e0.png 219,39KB
13 descargas
