apuntes de make

Después de una semana renqueante por culpa de una gripe, al visitar las news de C3 me encuentro con que Rodrigo Soto ha elaborado una exahustiva explicación de como usar la utilidad make para compilar y enlazar una aplicación. Está en http://apuntesc3.tripod.cl/tlink32/tlink01.html y está realmente bien explicado. Son esas cosas de las que mucha gente presume saber pero sólo están al alcance de unos pocos.

funcionamiento de i18n en xHarbour

Uno de los temas de los que ultimamente hablo con mucha gente es del i18n de xHarbour, de lo bueno y de lo malo que tiene y de cómo intentar dar soporte de internacionalización en Harbour o en C3. Ya hice un primer post sobre el tema, pero recapitulamos, pues creo que el personal está perdido.

La manera de acometer la i18n en xHarbour es utilizar la llamada a la función i18n() para las cadenas que queramos traducir que pasaremos como parámetro. Una vez hecho esto generamos una lista de cadenas que se guardan en un fichero con extensión .hil Para ello llamamos al compilador con el parámetro -j, algo así como:

\xharbour\bin\harbour colossus.prg  -jes_ES.hil -i\fwh24\include;\xharbour\include -n</p>

Con esto lo que hace el compilador es localizar todas las cadenas que están como parámetros de la función i18n() en el archivo fuente colossus.prg y las mete ordenadas en el fichero es_ES.hil. Esto lo hacemos para todos los fuentes de nuestra aplicación, con la particularidad de que el proceso es acumulativo, es decir que las cadenas del fuente se acumulan al archivo .hil. Por eso se aconseja borrar cada vez el fichero .hil y generarlo por completo.

Una vez tenemos el fichero .hil lo traduciremos al idioma que queramos usando la utilidad hbdict que se encuentra en \xharbour\utils\hbdict y al que pasamos como parámetros los archivos de entrada – que hemos generado previamente – y el de salida que guardará la traducción hecha y que el programa genera si no existe. Con este programa traducimos una a una las cadenas que se encuentran en el fichero .hil y lo guardamos en un fichero con extensión .hit. Desde dentro de nuestro programa lo único que haremos es decir en que idioma queremos que se muestren las cadenas con las siguientes instrucciones:

HB_I18NSetLanguage( "en_US" )
REQUEST HB_LANG_EN
HB_LANGSELECT('EN')</p>

Si no decimos nada el programa mostrará las cadenas tal como aparecen en las llamadas a la función i18n(). El fichero .hil no se incluye nunca en la distribución, ya que se trata de un archivo de trabajo que sirve como guia para realizar la traducción con el hbdict. Sólo incluiremos en nuestra distribucíón el archivo .hit del idioma en que queramos que esté nuestro programa.

Ventajas de este método:

  • Que está todo hecho y funciona bien, salvo algo que comentaré más adelante.
  • Si añades una cadena nueva al fuente, regeneras el archivo .hil y llamas a hbdict, este acopla el .hil nuevo al .hit viejo y unicamente tienes que traducir la cadena nueva. De alguna manera hbdict tiene memoria. No se cómo lo hace pero lo hace.
  • Los ficheros .hit se cargan internamente en arrays de manera que la ejecución del programa no se ralentiza. Además tiene un formato de texto bastante extraño y está a salvo de que nadie meta las narices ahí.

Problema: que al ser hbdict un programa en modo texto usa páginas de códigos con lo que si usas acentos abiertos y cedillas no hace bien la traducción. Esto me está pasando con la traducción de Colossus a catalán, y por eso estoy haciendo un programa en Windows similar. De momento bilingüa tiene esta pinta y cuando lo termine será una contribución a xHarbour y el código estará disponible.

La menera amanuense de hacer esto es meter las cadenas en un DBF con tantos campos como idiomas y cade vez que tengas que traducir algo tirar del fichero. El problema que veo es que tienes otro DBF en tu aplicación, seguramente esto será más lento que el sistema de xHarbour y que estás más expuesto a que te toquen la traducción con cualquier herramienta que abra DBF. Recordar que con el método xHarbour el .hil nunca se distribuye, por lo que no se puede usar hbdict para tocar a mano una traducción ya hecha.

¿ Opiniones ?

fivewin.info

Fivewin.info es – era – una de las mejores webs sobre Fivewin. Mantenida por Patrick Mast, recogía noticias sobre Fivewin, aportaciones del autor de la web y de otros usuarios a Fivewin. Desde hace meses está sin actualizar. Patrick tomó la decisión de participar empresarialmente en xHarbour.com y ha dejado de mantener la web, algo por otra parte totalmente entendible. En un futuro próximo xharbour.com pretende ser competidor de Fivewin con su propio GUI y Fivewin.info era uno de los puntales de Fivewin. Lo bueno de Fivewin.info era que tenía actualizaciones casi a diario y eso creaba un gran sentimiento de comunidad. Todos los fivewiners teniamos un sitio de referencia donde aparecían las noticias más importantes de nuestro entorno de desarrollo favorito.

Han surgido otros intentos de hacer portales basados en lenguajes xbase como Olivares2000 y Puertosur, pero, siento decirlo, no es lo mismo. Quiza sea porque estos dos sitios están restringidos a usuarios en español, pero desde que Fivewin.info dejo de actualizarse parece como si hubiera menos usuarios de habla inglesa de Fivewin o es que los que hay hacen menos ruido que antes. Una cosa que no entiendo es porqué Antonio Linares no crea un sitio parecido… creo que es un error de estrategia monumental. Lo cierto es que Fivewin ha perdido apoyos importantes y eso a la larga puede pasarle factura.

Una cosa que me hizo mucha gracia las primeras veces que visité Fivewin.info fue la foto de Patrick en la portada. Luego comprobé que era de mucha utilidad: en la reunión de Olivares2000 en Marbella iba hablando con Manuel Calero hacia la sala donde se iba a celebrar la reunión y vi dos hombres con bigote dentro de la sala. Uno era Patrick, lo conocí enseguida por la foto de su web, y le pregunté a Manuel quien era el otro. Me contestó: Antonio Linares. Vaya, pensé, conozco antes a Patrick que al padre de la criatura. Antonio, creo, no tiene ninguna foto en su web.

Folders XP con Xailer

A raiz del post sobre los folder XP con FWH en los comentarios se la librado un pequeño intercambio de opiniones. Por alusiones, José Giménez posteaba un enlace a un ejemplo de Xailer donde se puede ver esto:

No es exactamente igual que mi diálogo de Colossus que mostraba en el artículo mencionado, pero desde luego que las trasparencias están bien resueltas.

folders XP con FWH ¿ misión imposible ?

En el build de Julio de 2003, FiveTechSoft anunciaba la siguiente mejora en su librería FWH:

* Enhancement: Windows XP true folders! are ready for FWH/FW++. They are backwards compatible with your existing folders. All you have to do is change «TFolder» into FOLDER32 (or SysTabControl32) into your resources. No source code changes are required!

Como esto era algo que llevaba buscando bastante tiempo para incorporar a mis programas compré la citada actualización de FWH. Al probar el control, me encontré que éste no funcionaba bien. Las pestañas se pintaban bien y el cuerpo del folder hacía el degradado de los folder de XP, pero los controles estáticos hacían la trasparencia sobre el color del diálogo que había detrás en vez de sobre el color del folder. Asi:

Puesto al habla con FiveTechSoft estuve 2 meses esperando una solución al problema. La solución que me dieron era quitar el brush NULL del cuerpo del folder, de manera que se perdía el degradado que hace XP sobre los folder y este queda con el mismo color que la trasparencia. Comentando la linea donde se asigna el brush NULL a los diálogos del folder:

#ifndef __CLIPPER__
// oDlg:SetBrush( TBrush():New( "NULL" ) ) //byhDC
#endif

y después de ajustar los valores de coordenadas en el método Initiate del control

::aDialogs[ n ]:SetSize( ::nWidth()- 8, ::nHeight() - ::nFdHeight - 4 )

el ajuste del diálogo del folder no es total, pues queda una linea en blanco a la izquierda del diálogo que no he conseguido quitar. La cosa queda de esta manera:

O sea folder de XP a medias. Una posible solución sería pintar el dialogo de blanco o de un color de los que XP usa para el degradado, pero esa es una mala solución. Nunca se deben pintar controles con un color fijo, pues estamos yendo contra el principio de uniformidad del interfaz de usuario que debemos respetar. Si pintase el diálogo del folder de color blanco, un usuario de Windows98 o Windows2000 vería las pestañas en gris – o en el color del diálogo – y el cuerpo en blanco, lo cual sería una chapuza monumental.

Puesto de nuevo en contacto con FiveTechSoft sobre la manera de hacer diálogos como este:

la respuesta es que realmente estos diálogos son un tipo especial de diálogos llamados Property Sheet y que son como Wizards que implementa el propio Windows. Lo que no se puede hacer con WindowsXP – según FiveTechSoft – es usar folders de XP dentro de un diálogo donde haya otros controles fuera del folder además de los botones de Aceptar y Cancelar.

Mi gozo en un pozo.

Postdata. El caso es que a mi me suena haber visto un ejemplo de un diálogo así en un test de Xailer que me envió José Giménez antes del verano, pero con los últimos cambios de xHarbour no me funcionan los ejemplos que tengo de Xailer.

ya funciona bien la i18n de xHarbour

La semana pasada Giancarlo Niccolai corrigió los ultimos errores en hbdict, la herramienta de traducción de diccionarios que utiliza la i18n de xHarbour. Con estas correcciones, xHarbour ya cuenta con una característica de lenguajes de proramación modernos como es la facilidad de internacionalización de los programas. Para mi esto es muy importante pues aspiro a tener versiones multiidioma de mis programa a corto plazo. De momento ya tengo Colossus traducido a inglés y estoy comenzando con la traducción a Catalán. Después seguirán los otros programas, tan pronto como vaya migrandolos a xHarbour.

Quiero agradecer a Giancarlo Niccolai el trabajo que ha hecho con la i18n, y su paciencia conmigo. He de decir que además de un brillante programador ha demostrado tener una enorme paciencia. Ha habido muchas veces en que le he escrito diciendole que la i18n no iba bien, y siempre se ha prestado a aislar el problema mediante test y ejemplos. Algunas noches le escribía pasadas la 1A.M. y cuando me levantaba a las 7A.M. ya tenía su respuesta en mi buzón de correo. Creo que todos los correos me los ha contestado en menos de 5 horas y encima cuando ya conseguimos que todo funcionase bien me escribió: Very well. Again, thanks for your support 🙂.

fsdi para xharbour

He adaptado mi clase fsdi – full single document interface – para xHarbour. El resultado es este:

Como se puede ver es un programa a 32 bits, que coge perfectamente el tema de mi escritorio gorilla. Para funcionar se necesita un build de FWH posterior a junio de 2003, pues había un error en las versioes anteriores que hacía que funcionase mal la herencia de la clase Dialog.

La clase fsdi para xharbour la puedes descargar aqui – fichero de 512KB con fuentes y ejecutable para los no fivewineros. Es freeware, pero mantengo el copyright sobre ella y agradecería a los posibles usuarios de la clase que me escribieran para darme su opinión sobre la misma.

i18n en xharbour – 2

Estoy probando la i18n en xHarbour para aplicarlo en Colossus y es sumamente fácil de utilizar. En la documentación sobre la i18n hay una errata que me ha hecho atascarme un rato: donde dice…

I18N_SetPath( "c:\MyPathDifferent" )
I18N_SetLanguage( cLang )

debe decir

HB_ I18NSetPath( "c:\MyPathDifferent" )
HB_I18NSetLanguage( cLang )

Pero lo más impresionante de todo es que HbDict recuerda que cadenas has traducido ya del idioma base aunque regeneres el fichero de idioma.

Impresionante trabajo el de Giancarlo Niccolai.

i18n en xHarbour

Una nueva característica que ha pasado casi desapercibida en la versión 0.81 de xHarbour es la de internacionalización de la aplicación. La internacionalización – i18n porque entre la i y la n hay 18 letras – de una aplicación supone tener herramientas automáticas para traducir cualquier literal que muestre la aplicación en las distintas lenguas a las que se la quiera traducir. Muchos lenguajes modernos incorporan herramientas de i18n, que son muy apreciadas por los programadores de un mundo cada vez más globalizado.

Si no tenemos herramientas de i18n podemos hacer la traducción de los mensajes de varias maneras:

  • incrustando la i18n en el código, es decir meter todos los literales en el código y mostrando unos u otros en función de una variable. Esto es una auténtica burrada, con perdón.
  • almacenando los literales en un RC. En este caso lo normal es tener un RC para cada lengua a la que traduzcamos nuestra aplicación, aunque también podremos tenerlos juntos en el mismo RC y elegir cual mostrar. En cualquier caso en el programa tendremos que recuperar la cadena del RC para mostrarla. En el caso de tener que mostrar una etiqueta haremos algo como esto:
    REDEFINE SAY PROMPT LoadString(GetResources(),1164) ID 20 OF oDlg
    REDEFINE SAY PROMPT LoadString(GetResources(),1163) ID 21 OF Odlg
    

    ¿ Problema ? Que codificamos a ciegas, pues ¿ cual es la cadena 1164 ? Tenemos que estar continuamente pasando del editor de código al editor de recursos para saber que estamos diciendo al usuario y además llevar cuidado de no repetir cadenas. Un rollo.

Ahora en xHarbour 0.81 cada cadena a i18n la pasamos como parametro a una función que se llama precisamente i18n(), con lo que tenemos algo asi:

REDEFINE SAY PROMPT i18n("Introduzca la materia") ID 20 OF oDlg
REDEFINE SAY PROMPT i18n("Materia:")              ID 21 OF Odlg</p>

El lenguaje nos proporciona herramientas para generar un diccionario de terminos a traducir y realizar la traducción de los mismos. Una vez traducido el diccionario, lo único que tenemos que hacer desde nuestra aplicación es seleccionar el lenguaje en que mostraremos los mensajes.

xHarbour va pareciendo cada vez más un lenguaje moderno.

código escrito

Hoy se inaugura codigo escrito – mis apuntes sobre programación el nuevo blog de Jaime Irurzún. Desde aquí quiero enviar mis mejores deseos de éxito y continuidad para el nuevo proyecto de Jaime y animar a todos los que leen este blog a que se decidan a compartir sus conocimientos y experiencias.

Mi primer contacto con Jaime fue el 29 de septiembre de 2001. Compró mi Cuaderno de Bitácora y al poco tiempo comencé a recibir correos suyos. Me preguntaba acerca del lenguajde programación usado y cosas así. Le contesté y le di direcciones de internet para que conociera las herramientas que yo uso. Fuimos intercambiando correos y un dia me dijo que quería programar con Clipper y Fivewin. Yo le animé a hacerlo y al poco tiempo creó su propia web donde ha hecho una fantástica labor de recopilación de información y desde donde se pueden descargar un par de programas suyos que incluyen el código fuente. Habitualmente participa en los foros de Fivewin y es de los que contesta muchos correos de los novatos que muchos de los más viejos de lugar – y me incluyo – pasamos por encima.

He dejado para el final un detalle: Jaime tiene 17 años y estudia Bachillerato. Si la comunidad xBase quiere continuar, necesitamos muchos Jaimes, muchos nuevos programadores que se acerquen a nuestros lenguajes. Y para ello necesitamos que los lenguajes xBase sean atractivos para los nuevos programadores. ¿ Cómo hacerlo ? Pues cada uno con su granito de arena. Unos participando en los desarrollos de [x]Harbour, FW, Xailer, C3. Otros dándolos a conocer y demostrando que los lenguajes xBase siguen vivos.

¡ Ánimo Jaime y suerte !