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 100% 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:

20030925a.gif

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:

20030925b.gif

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:

20030925c.gif

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.

upx

Estos dias estoy probando UPX – the Ultimate Packer for eXecutables. Es un compresor con licencia GNU, pero que sus desarrolladores permiten que se use en aplicaciones comerciales. Permite comprimir ejecutables con múltiples formatos, entre ellos el Win32/PE de Windows. El ratio de compresión es muy bueno, por ejemplo Colossus pasa de 1.764.352 bytes a 564.248 bytes. En las pruebas que he hecho con Windows98 y WindowsXP, el ejecutable comprimido no ha dado ningún problema.

UPX se puede descargar desde http://upx.sourceforge.net/.

actualización Olvidé decir que UPX sólo comprime ejecutables de 32 bits. No sirve para aplicaciones hechas con Clipper+FW, pero si para xHarbour+FWH.

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

registros de programas ligados a la máquina

Hay un tipo de registro de programas que encuentro especiamente molesto, hasta tal punto que intento siempre no tener que usar los programas que lo utilizan. Me refiero a los registros de programas ligados a máquinas. En este tipo de registro – aunque quiza habría que llamarlo protección – el programa genera una clave en función de la máquina donde está instalado y para desbloquearlo y poder usarlo con todas sus funciones se necesita una contraclave que te proporciona el programador.

El motivo más importante por el que no me gustan este tipo de licencias – protecciones es que si compras uno de estos programas realmente no tienes el programa. Para poder usarlo dependes de que te manden la dichosa contraclave, y eso no me parece justo. Entiendo que es una medida de protección por parte del programador, pero de momento no la comparto. Creo que cuando un usuario registra un programa tiene una serie de deberes como usarlo en un sólo PC, no descompilarlo, etcétera, pero también tiene derechos y entre ellos está el de poder usar el programa en la manera que estime conveniente siempre que cumpla la licencia de uso. Si un usuario tiene 52 ordenadores, y cada semana del año quiere usar el programa en un PC distinto está en su derecho, o al menos eso creo yo.

editor de recursos de PellesC

A raiz un post de Antonio Linares sobre el compilador de C que se usan en la versión comercial de xHarbour llegué a la web de un compilador C gratuito llamado PellesC. Viendo la web me llamó la atención las capturas de pantalla que mostraban un editor de recursos que tenía muy buena pinta. Lo he bajado y he estado jugando con el editor de recursos y parece que funciona muy bien. Tiene editor de dialgos, bitmaps, iconos, cadenas,… y lee bien los ficheros .RC o .RES generados con otros editores de recursos.

Estas últimas semanas he estado bajándome y probando todos los editores de recursos que he encontrado y todos tenían alguna pega: uno sólo editaba recursos dentro de ejecutables, otro sólo en DLL, otro no leía bien los .RC generados por el editor de recursos que uso,… todo eran problemas.

Voy a seguir probando el editor de recursos del PellesC, pero creo que tiene muchas posibilidades de convertirse en mi nuevo editor de recursos.

el peor de los errores

El peor de los errores es el que no puedes reproducir. No sabes porqué surge, ni eres capaz de anticiparlo. Asalta tu programa y tu no eres capaz de defenderlo.

Eso es lo que me está pasando con el soporte de i18n de xharbour. Primero daba errores al tomar como lenguaje base uno distinto del inglés. Giancarlo Niccolai lo corrigió permitiendo que se tome como base cualquier lenguaje. Después el problema fue que había cadenas que no se traducian. Generé 50 veces el diccionario base y revisé la traducción. Todo correcto, pero habia cadenas que quedaban sin traducir. Pensé que el problema era el uso de las letra ñ, así que cambié contraseñas por claves en todas las cadenas que mostraba el prograna. Seguía fallando, pero ahora no traducía cadenas que antes sí se traducian y viceversa.

He vuelto a escribir a Giancarlo, que es quien ha hecho el soporte de i18n para xHarbour, y me está ayudando a resolverlo. Parece que el problema está en el algoritmo de ordenación del array donde se almacenan las cadenas traducidas. El caso es que con un build de xHarbour descargado hoy del CVS la i18n no funciona bien. La verdad es que no se por donde atacar el problema. Giancarlo se está portando fenomenal conmigo y debe pensar que soy un torpe, pero no se que demonios está pasando.