mi amigo invisible

Corren tiempos difíciles para los programadores que usamos FWH. Hace sólo un par de años, en mis contactos de messenger había una docena de FWH’ers. Ahora los contactos siguen estando ahi, pero ausentes.

Sin embargo, tengo un amigo invisible escondido por ahí. No suele postear en los foros, ni tiene página web, ni nada de nada. Está ahí, escondido en el messenger, sin hacer ruido y de pronto dice Hola José Luis y coimenzamos a chatear. Mi amigo invisible es un gran programador, conoce muy bien FWH y tiene un montón de clases modificadas, algunas de ellas realmente espectaculares. Hace poco publiqué un mensaje en el foro de FWH preguntando por las cebeceras de xbrowse con temas. A los pocos dias mi amigo invisible me abordó en el messenger y me dijo como tenía que modificar la clase para conseguir lo que quería. Después de varios intentos y varias noches más de messenger… voilà

xbrowsecontemas.jpg

Realmente espectacular.

Es curioso, sólo lo he visto una vez a mi amigo invisible. Fue en la reunión de Olivares2000 en el año 2005. La verdad es que no hablamos mucho, pero desde entonces poco a poco hemos tenido mayor relación, y me alegro mucho cada vez que lo veo por messenger. Si lo volviera a ver, no desperdiciaría la oportunidad de conocerlo un poco mejor.

canalfive vitaminado

Desde mis inicios programando con Fivewin y después con FivewinHarbour, uno de los componentes principales de mis programas han sido los controles de CanalFive. El primero que use fue su grid, luego sus folders y su calendario, todos en 16 bits. Con estos controles conseguía una usabilidad y potencia en mis programas que no conseguía con FW. Los controles de Canalfive llegaban donde no llegaba Fivewin. Rebuscando en el archivo de este blog he encontrado un post donde hablaba de los folders de Canalfive y la mejora de interfaz que supuso para mi tenerlos a mano.

Despues de unos años de hacer como el Guadiana, aparecer y desaparecer, Canafive retomó la realización de controles con sus taskboxes y poco a poco ha ido realizando más controles.

Hasta ahora Canalfive tenía un sólo desarrollador, que es mi amigo Paco. Conocí a Paco hace unos 12 años en el trabajo, de hecho conocerle es lo mejor que me ha pasado en mi trabajo, y enseguida hicimos una gran amistad. Es un tio fenomenal, de los que son mejor persona que programador y eso es tela pues programa que se las pela. Pero ahora ha unido fuerzas a dos de los mejores programadores Xbase que existen en el mundo mundial que son Oscar Lira y Victor Manuel Tomás – listo el pollo !! -. Están creando nuevos controles, pero ya no sólo para FivewinHabour, sino también para Xailer y VisualXharbour. ¿ Como hacen que un control funcione en los tres entornos ? Ni idea, pero aqui entra en juego una de las máximas de Paco: tan importante como saber, es saber quien sabe. Y estos tres saben mucho.

Pasen y vean la nueva web de Canalfive.

PD. Mientras escribía este post en el fin de semana, he visto que René ha escrito un post similar donde pone imágenes de los controles de Canalfive.

fsdi2006

Desde hace bastante tiempo vengo usando en mis programas una clase llamada FSDI que pretende emular un interfaz de documento único a ventana completa. El primer post donde hablaba de esto se llamaba Full Document Single Interfaz y estaba en Software* que fue mi primer blog. Luego hubo modificaciones de la clase, primero con su adaptación a xHarbour, luego el diálogo contenedor pasó a ser no modal, y hace poco conseguí que el diálogo contenedor se redimensionara al redimensionar la ventana principal de la aplicación gracias al uso del método SetSize().

Ahora publico como ha quedado la clase FSDI con todas estas características, así como un pequeño ejemplo de como montar la ventana principal y un diálogo FSDI sobre ella. El código que acompaña al ejemplo es el siguiente:

  • main.prg – punto de entrada de la aplicación y construcción de la ventana principal. El redimensionamiento de esta se hace en la función ResizeWndMain(). Está incluido el soporte de fuentes grandes en caso de que el usuario de la aplicación las tenga seleccionadas.
  • tfsdi.prg – la clase FSDI.
  • pcustomer.prg – construcción de un diálogo FSDI con la TaskBar de Canalfive a la izquierda y una rejilla de datos a la derecha.
  • tabs.prg – las tab que uso para la parte inferior del diálogo fsdi.

Aquí está el ejemplo para descargar: FSDI2006

completando FSDI: un método llamado SetSize()

Una de las cosas de las que carecía nuestro interfaz TFSDI era del ajuste a la ventana principal de la aplicación al redimensionar esta. En el post anterior se ve en una de las capturas que se publicaron en el artículo de PcActual como queda un trozo de ventana sin el diálogo FSDI encima. Esto es debido a que al crear el diálogo FSDI calculamos las coordenadas que debe tener este y lo ponemos en la zona cliente de la ventana principal de la aplicación, pero al cambiar el tamaño de esta no sabiamos como ajustar el diálogo FSDI con sus controles.

La verdad es que la cosa parecía difícil de resolver. Habiamos hecho varios intentos sin resultado, y en la última reunión de GO2000 José Luis Capel nos enseñó una aplicación con un aspecto similar a las nuestras pero con el ajuste a la ventana perfectamente conseguido. La manera de hacer esto por parte de José Luis era usando paneles, y estuve preguntándole varias cosas pero sin resultado. Lo de los paneles era un auténtico lio, o eso me parecía. El caso es que buscando la manera de ajustar di con un ejemplo en la carpeta SAMPLES de FWH en el que nunca había reparado: fwbios.prg. En este ejemplo se hace un ajuste de un listbox definido por código a una ventana mediante el método SetSize() de aquel, invocado al redimensionar la ventana. El caso es que el método SetSize() pertenece a la clase Window y lo heredan todas las clases que derivan de ella, o sea
todos los controles. Este método permite ajustar el tamaño de cualquier control que haya sido definido por código, como por ejemplo el taskbar, xbrowse y tabs que uso en mis diálogos FSDI además del propio diálogo. Y yo sin enterarme ni de que existía este método.

Lo único que he tenido que hacer es que los objetos taskbar, xbrowse y tabs que aparecen el cada diálogo FSDI sean datas de mi clase TApplication que es la que controla la ventana principal, de manera que al redimensionar la ventana pueda acceder a estos controles para ajustarles el tamaño mediante el método SetSize(). En breve publicaré la edición gratuita de Azeta que es el primer programa donde implemento esto.

fuentes grandes en FWH

Una de las cosas que nos están pidiendo los usuarios de nuestros programas ultimamente es la posibilidad de modificar el tamaño de la fuente de los mismos. Con el aumento de tamaño de los monitores actuales es perfectamente posible tener una fuente grande para no tener que forzar la vista. Es posible definir en el programa una fuente y un tamaño, pero creo que la manera correcto de hacer esto es que el usuario defina en Windows que fuente y que tamaño quieren usar y que los programas tomen la fuente de la configuracíón de Windows. Además Windows permite usar el sistema de alisado de fuentes ClearType que permite tener una fuente muy nítida en monitores grandes.

Un formulario típico con fuentes pequeñas sería el siguiente:

20060306e.jpg

Para pasar el programa a fuentes grandes, o mejor dicho, para que siempre coja las fuentes del sistema, tenemos que evitar usar tamaños de fuente fijas en nuestro programa y coger la del sistema. En FWH existe la función GetSysFont() que permite coger la fuente del sistema. Contando que al usar fuentes grandes el propio Windows se encarga de redimensionar los diálogos tenemos que nuestro anterior diálogo se ha trasformado en este:

20060306c.jpg

Perfecto, ¿ no ?

Pues no. Usando GetSysFont() cogemos las fuentes del sistema, pero no se el motivo por el cual determinadas partes del formulario no usa el suavizado de fuentes cuando se le pide a Windows que lo haga. Así, si nos fijamos en la imagen de arriba vemos que realmente hay dos tipos de fuentes en el diálogo, una para los GET y otra para los SAY.

Fijándonos en el menú de la aplicación veremos que este sí que usa el suavizado de fuentes, tal como se aprecia en la siguiente imagen:

20060306g.jpg

¿ Que hacer para que la aplicación tome la fuente de Windows con el suavizado ? La solución me la dió mi amigo Paco – gracias otra vez más – y consiste en usar las siguientes funciones:

//___ manejo de fuentes - Paco García 2006 ___________________________________//
#pragma BEGINDUMP
#include "Windows.h"
#include "hbapi.h"
HB_FUNC( GETDEFAULTFONTNAME )
{
LOGFONT lf;
GetObject( ( HFONT ) GetStockObject( DEFAULT_GUI_FONT )  , sizeof( LOGFONT ), &lf );
hb_retc( lf.lfFaceName );
}
HB_FUNC( GETDEFAULTFONTHEIGHT )
{
LOGFONT lf;
GetObject( ( HFONT ) GetStockObject( DEFAULT_GUI_FONT )  , sizeof( LOGFONT ), &lf );
hb_retni( lf.lfHeight );
}
#pragma ENDDUMP

y en el programa definir de esta manera la fuente de la ventana principal:

::oFont = TFont():New( GetDefaultFontName(), 0, GetDefaultFontHeight(),, )</p>

y luego heredar en las ventanas y dialogos del programa esta fuente. Con esto nuestro diálogo queda de esta manera:

20060306d.jpg

donde se ve claramente que ya toma bien la fuente del sistema con el suavizado de bordes.

El último paso para que nuestra aplicación FWH tome bien las fuentes del sistema es modificar las clases de FWH que usan fuentes de paso fijo, como MsgBar, MsgItem y Ttabs para que cojan la fuente de nuestra ventana principal.

Las próximas versiones de nuestros programas ya funcionarán bien con fuentes grandes.

como ser un micro-isv

Este finde pasado estuve en la reunión de Olivares2000 que se celebró en la sede de Atisa. Tengo que decir que la organización fue excelente, la sala estaba completamente equipada y todo funcionó de maravilla, incluida la videoconferencia con Walter Negro. Quiero agradecer desde aqui a José Alfonso Suarez y al personal de Atisa por el exquisito trato recibido.

Mi contribución a la reunión fue una charla sobre el tinglado este de ser un micro-isv. Como hubo algún asistente que se interesó por la presentación, aquí dejo el PDF con el contenido de la charla.

GO2005 y más

Este fin de semana toca reunión de Olivares2000. Nos vemos en Madrid un grupo de entusiastas del xbase para contarnos cosas, y como a cada uno de nosotros le tiran cosas distintas tenemos mucho que contar. Yo voy a contar en que consiste esto de ser un micro-isv y ya tengo preparada la charla con presentación – OOo – incluida. Probablemente publique la presentación aquí o en el sitio de GO2000 cuando pase el fin de semana. Este año vamos a ser bastantes asistentes, y un ingrediente para mi muy importante de cosas como esta es el contacto humano con amigos con los que habitualmente te relacionas via internet, bien por correo o por msn. Por cierto, que este año mi amigo Manuel pincha y no puede venir. ¡ Killo, te voy a echar de menos !

Al margen de esto estamos de lleno en periodo de betatest de las nuevas versiones de Cuaderno de Bitácora y el Puchero. Aparte de lo que son nuevas funcionalidades de los programas, lo que más nos ha costado decidir es el nuevo modelo de distribución basado en una edición gratuita y otra de pago con funcionalidades añadidas. Y es que muchas veces las deciones estratégicas son las más dificiles de tomar, mucho más que picar código. De todo esto hablaré el sábado a las 10 de la mañana. Para asistir a las conferencias hay que registrarse en la web de Olivares2000.

la camiseta del XAAC

Esta semana me ha llegado la camiseta del XAAC, el concurso de programación xHarbour que ganamos. Y nada más llegar la camiseta, van los fenómenos estos y les da por cambiar la web de xHarbour … y el logo. Pero vamos por partes.

La camiseta es muy bonita. Yo ya tenía 2 que compré en Cafepress, pero de mi talla. La que han mandado ahora – o al menos la que me ha llegado a mi – es de talla XXL y me viene un pelín grande. Así que si alguien tiene una de talla L que me lo diga para cambiarlas.

20050923.jpg

La nueva web de xHarbour está muy bien. Realmente han hecho un trabajo estupendo y se nota el buen hacer y el sentido empresarial de Patrick Mast. Es una web superprofesional, con perlas como el xHDN o el impresionante archiv de Guias Norton.

Pero lo del cambio de logotipo la verdad es que no me ha gustado. Me recuerda mucho al logo de los x-men que leía de joven, cuando el guionista era Claremont y los dibujaba John Byrne. Pero sobre todo es que para mi el logo de xHarbour es verde y azul, como las latas de CocaCola son rojas y las de Pepsi azules. ¿ Alguien se imagina una lata de CocaCola azul ? Pues yo no me hago a la idea del logo de xHarbour amarillo y negro, pero será cosa de acostumbrarse.

tooltips de balón en FWH

Muchas veces la diferencia entre un programa y un buen programa está en los detalles. Por eso, un programador debe visitar con asiduidad los foros del lenguaje o herramienta de desarrollo que utiliza y estar al tanto de cualquier comentario que se pueda hacer sobre el mismo.

Hace un par de semanas en el foro de FWH Antonio Linares publicó la manera de cambiar los tradicionales tooltips cuadrados por unos de tipo balón. Los cuadrados son estos:

20050919a.jpg

Para conseguir los tooltips de balón lo único que hay que hacer es ir al código fuente de la clase Window y quitar un comentario que aparece en la linea 2762 – o simplemente buscar ballon en el prg -. Hay que dejar la llamada a CreateTooltip con el último paráametro a .t.

hWnd = CreateToolTip( Self:hWnd, cToolTip, .t. ) // for ballon tooltips !

Luego se recompila la librería y nuestro programa. Ya tenemos tooltips de balón 😉

20050919b.jpg

usando TDbf

Hasta hace poco nunca había usado nada para manejar DBF que no fueran los comandos y funciones estándar de clipper y luego de xHarbour. Hace unas semanas comencé el desarrollo de una aplicación que tiene que ejecutarse en red y me planteé mirar las distintas clases para manejo de DBF que existen para xHarbour.

Haciendo caso de mi amigo Manolo y de algún otro consejo recibido via messenger me decidí a probar TDbf de Manu Expósito. Me bajé la clase desde su grupo de Yahoo y me puse a probarla. El ahorro de código que se produce al usar esta jerarquía de clases – como a Manu le gusta llamarla – es realmente impresionante. La clase crea automáticamente una data para cada campo del fichero que se manipula, con lo cual no tienes que definir campos ni hacer asignaciones. Además la clase maneja un buffer que es el que contiene estas datas, de manera que puedes cargar el buffer desde tu dbf y guardar los datos con una llamada a un método de la clase. Un mantenimiento básico usando TDbf sigue esta estructura:

IF NUEVO_REGISTRO
   oDbf:Blank() // pongo en blanco el buffer
ELSEIF MODIFICACION
   oDbf:Load() // cargo el buffer desde la dbf
ENDIF

DEFINE DIALOG oDlg RESOURCE "EDIT" OF oParent

REDEFINE GET aGet[1] VAR oDbf:TaCodigo  ;
   ID 12 OF oDlg UPDATE           		;
   PICTURE "@!"                        ;
   VALID Clave( aGet[1], nMode )
...
ACTIVATE DIALOG oDlg	;
   ON INIT DlgCenter(oDlg,oApp():oWndMain)</p>

IF oDlg:nresult == IDOK
   lReturn := .t.
   IF NUEVO_REGISTRO
      oDbf:Insert()
   ELSEIF MODIFICACION
      oDBF:Save()
   ENDIF
ENDIF

Además, Manu está preparando una TDbf Pro para antes de que acabe el año y que estará escrita en gran parte el C, con lo cual irá mucho más rápida que la actual clase. Ganas tengo de verla.