Una de las diferencias que existen en programar un GUI para el API Win32
y GTK+, es que , mientras en el Win32 todo termina en una llamada a una
funcion CALLBACK , donde se despachan todos los eventos, en GTK+ la cosa
cambia radicalmente, ya que a parte de conectar manualmente los eventos
que queramos conectar, existe una callback distinta.
Eso supone un trabajo extra con respecto a otras GUIs para [x]Harbour,
puesto que a veces resulta que te viene como parametro una estructura,
y ahi esta el problema, harbour no tiene NI IDEA de como tratar una estructura
de C. ( Recordad que esto corre en los dos compiladores, NO SE HACE
USO DE EXTESIONES DEL LENGUAJE )
Hasta ahora, a parte de que no he tenido la necesidad de pasar ninguna
estructura, si no , que he codigo los miembros que mas me interesaban,
y es lo que recibia el method , por ejemplo, On_XXX( oSender, nKey, nType ).
Asi tengo 2 parametros , nKey y nType, que realmente son miembros de una
estructura de C.
Esto, si bien esta bien, le veo un problema, y es que no informa realmente
de todos y cada uno de los miembros de la estructura.
Imaginemos que vamos a controlar la señal , "key-press-event".
Si conocemos un poco de GTK+, veremos que el prototipo en C de la funcion
callback a donde saltara, pasara los siguientes parametros:
gboolean user_function (GtkWidget *widget,
GdkEventKey *event,
gpointer user_data);
Vemos como GdkEventKey, es un estructura que contiene bastante informacion.
Dicha estructura es la siguiente:
struct GdkEventKey {
GdkEventType type;
GdkWindow *window;
gint8 send_event;
guint32 time;
guint state;
guint keyval;
gint length;
gchar *string;
guint16 hardware_keycode;
guint8 group;
};
Ojo , todo esto esta explicado perfectamente en la documentacion disponible de GTK+ y hay
miles de ejemplos, molestaros en buscar si quereis saber mas. ;-)
Bien, en la clase gEntry, aprovecho para conectar dicha señal, para poder controlar el
objeto oGet que la clase gEntry incorpora.
No se, es que el PICTURE de los GETS que tiene xBase, dificilmente lo pueden superar
en otros lenguajes, no entiendo por que narizes tienen un Edit, EditMask, etc..., uno
para cada cosa.
Ahora , lo que viene al method OnKey_press_event() va a ser un array simulando la
estructura que le corresponderia, o lo mas compatible posible.
Asi, tendremos:
METHOD OnKey_press_event( oSender, aEventKey ) CLASS XXXX
aEventKey[ 1 ] --> Miembro type de la struct GdkEventKey
aEventKey[ 2 ] --> Miembro window " " "
aEventKey[ X ] --> Miembro XXX " " "
Generalmente, la mayoria de los miembros a mi no me dicen nada, pero , como siempre,
algun dia a alguien le puede servir, y entonces, empezamos OTRA VEZ a retocar,
y es lo que quiero evitar.
De momento lo estoy reprogramando para la POO, tambien lo hare extensible al uso de
las funciones.
A parte de esto, el programar de esta manera, de saltar directamente a los methods de las
clases, requiere prestar mucha atencion al ErrorSys, el cual he retocado ya unas cuantas
veces, y las que le quedan, porque una salida con el comando QUIT, puede llegar a ser
peor el remedio que la enfermedad.
Como Gtk+ funciona distintos al WINAPI en algunos aspectos, sobretodo cuando puedes
entrar en otro bucle de procesos de eventos, independiente de otra ventana, es necesario
ir saliendo de cada uno que tengas, ir "matando" todas las ventanas y dialogos que
tengas, etc..., cosa que en el WINAPI, seria trivial, aqui la cosa es bastante mas
complicada.
AH!! Si tuviera un array aWindows, eso seria trivial , aWindows[x]:End() ;-),
pero no dispongo de el, y no quiero disponer de el ;-)
De momento, mirare como implementar el saber lo que tengo en memoria en Harbour,
y como liberarlo.
Asi que tengo varios frentes abiertos, que para uno puede parecer complicado, pero
creo acertado terminar con los cimientos, para que el resto de los mortales pueden
terminar de edificar.
Asi, ejemplos que tenia, los he tenido que ir retocando, pues al cambiar cosas
internas, hasta el prepo, pues era totalmente imcompatibles, como por ejemplo,
estoy implementando que TODOS los widgets , los que sea logico, sean manejados a traves
del bSetGet(), de esta manera, el cambio producido en un widget, tendremos una variable
actualizada automaticamente con el valor que le corresponde.
Saludos.
Escrito por Rafa Carmona a las 30 de Diciembre 2004 a las 01:59 PM