Yo pensaba que , como ya iba, para que tocarlo....pero...., creo que los beneficios
saltan tan a la vista, que no me he podido resistir a ello....
T-Gtk , se aproxima al nivel de otras Guis muy profesionales, como Xailer,
en que 'abandona' el uso del famoso array 'aControls' a la 'Fivewin', es decir,
el salto desde que se produce desde el evento del sistema a la ejecucion de
nuestro codigo.
Podemos observar en la practica totalidad de Guis bajo Harbour, de las que
disponemos el codigo, como la implementacion se basa en recorrer un array.
Explicare esta técnica, hasta ahora usado por T-Gtk+.
Aunque como siempre he dicho, por cada desarrollador y Guis existente, habra
una tecnica distinta, puesto que el programar es un arte ;-)
¿ Que es lo que pasa desde el Evento del Sistema a la ejecucion de nuestro
codigo ?
Veamos por encima el esquema :
1-EVENTO DEL SISTEMA
2-SALTO DESDE LA CALLBACK A HARBOUR
3-RECORRIDO EN BUSCA DEL HWND Y SALTO AL METHOD
4-EJECUCION DE NUESTRO CODIGO.
Explicaremos ahora los pasos que se realiza hasta llegar a nuestra ejecucion
del codigo
EVENTO DEL SISTEMA
Cuando el usuario pulsa un boton, el sistema lanza un evento, donde Gtk+,
manda la señal "clicked", en GUIs basados puramente en el API Win32, reciben
el mensaje WM_XXXX correspondiente, a continuacion....
FUNCIONES CALLBACK A HARBOUR.
Cada vez que se produce un evento, las funciones callback que hemos conectado
seran las encargadas de saltar a Harbour y es aqui donde hay una implementa-
cion por cada GUI disponible para harbour.
¿ Y porque ocurre esto ? Cada programador quiere/tiene su propia
implementacion, por diversos motivos, por su nivel o capacidad de
programacion, etc... y aqui es DONDE vemos una diferencia sustancial entre
los distintos GUIS...
RECORRIDO EN BUSCA DEL HWND Y SALTO AL METHOD
Hasta ahora, usaba un array aControls, y saltaba desde la funcion callback
a una function en Harbour llamada Entry_Point() que recibia el puntero,
y el tipo de evento producido, asi como otros parametros.
Aqui teneis la funcion :
FUNCTION ENTRY_POINT( pWidget, cEvento, nKey, nType )
LOCAL nWidget := AScan( aControls, { | oControl | oControl:pWidget == pWidget } )
Local uReturn := .F.
IF nWidget != 0
uReturn := aControls[ nWidget ]:HandleEvent( cEvento, nKey, nType )
ENDIF
RETURN uReturn
Depues de buscar en el indice , se saltaba al HandleEvent() del objeto
correspondiente y se acabo.
Si bien este sistema esta bien, tiene una pega, es que si destruimos un
objeto en cuestion, debemos de quitar su referencia en dicho array, perdiendo
ademas mas tiempo entre eventos que se pueden producir en el sistema, porque
no vamos a dejar que vaya creciendo el array, porque si no, el sistema
se vuelve mas lento, por cada control que se cree.
Una forma que usaba T-Gtk, era, que cada vez que se destruia un control,
se quitaba su referencia en el array aControls.
IF cEvento == "destroy"
ADEL( aControls, nWidget )
ASIZE( aControls, ( Len( aControls ) - 1) )
RETURN .F.
Como podeis observar, se pierde tiempo en la creacion del control, se
pierde tiempo en la gestion del evento, y se pierde tiempo en su destruccion.
Y funciona, si funciona de maravilla, pero...
¿ Que pasaria si..., hacemos desaparecer el array aControls, y la funcion
ENTRY_POINT() ?
No creo que seais unos genios al observar que la cantidad de ciclos de reloj
que le quitamos a la CPU , asi como la gestion de la memoria es ENORME!!!
Ahora , T-Gtk+ se aproxima más a Xailer, puesto que Xailer tiene una gestion
interna MUY SOTISFICADA y ENORMEMENTE RAPIDA y por cierto COJONUDAMENTE resuelto!!
En mi intento de mejorar T-Gtk, y a unas ideas de Carlos Mora, más la ayuda
inestimable de Jose F.Gimenez, padre de Xailer, he podido implementar una
parte similar a la Xailer, es decir, 'SALTO' directamente al method
correspondiente, sin necesidad de tener ningun aControls, o algo similar.
Si antes saltaba al METHOD HANDLEEVENT y de ahi al METHOD CLICKED, a traves de la funcion Entry_Point(), por cada vez que se presiona el boton , por
ejemplo, ahora salta directamente al METHOD CLICKED, ademas , pasandole
el objeto , oSender, que a producido dicho evento.
Esquematicamente , quedaria asi, tal y como estaba T-Gtk :
ENTRY_POINT()
|--> METHOD HANDLEEVENT()
| -->METHOD CLICKED()
Ahora , simplemente, se convierte por arte de magia en:
METHOD CLICKED( oSender )
Xailer realiza esto y más, como en vez de saltar a un method , ejecute un
codeblock, que sera, logicamente el siguiente paso que voy a implementar en
T-Gtk+ ;-)
Realmente, creo, bajo mi punto de visto, que Xailer es realmente MUY BUENO,
en todos los aspectos, yo simplemente me da por mirar a bajo nivel, pero
ahi esta, teneis un AUTENTICO RAD en entornos XBASE, tan facil de usar
como el delphi.
Sinceramente, jamas crei que alguien fuese capaz de hacer algo parecido,
en el mundo xbase en el que nos movemos.
Asi, que T-Gtk+ va a ser reescrito un poco para soportar la nueva forma,
a la 'Xailer', para ir abandonando el estilo a la 'Fivewin'.
Espero que al menos os haya quedado claro un pelin las distintas formas
que hay dentro de nuestro mundo Harbour, de programar Guis.
Ojo, con ello no quiero decir ni insinuar que unas sean malas o bueas, si no,
que la implementacion es 'distinta', nada más, y que cada cual, al conocer las
distintas implementaciones, y saber como funciona el tinglado por debajo.
Saludos.
Escrito por Rafa Carmona a las 7 de Diciembre 2004 a las 11:18 AMRafa,
Aclararte que FWH/C3/++ usan la misma técnica que Delphi. Es decir, el propio control guarda el índice al array aControls en su procedimiento de ventana a bajo nivel, por lo que no hay ninguna busqueda y el salto es directo.
aControls se mantiene solo por comodidad y para brindarle más posibilidades de acceso al programador.
saludos,
Antonio
Escrito por Antonio Linares a las 10 de Diciembre 2004 a las 02:00 PMAntonio.
Tienes razon , no es aControls, es aWindows, siento el lapsus, pero la cuestion es la misma
Antonio, como bien sabes, yo no discrepo de la forma de implementantacion de unos y otros, cualquier es valida, siempre
que cumpla su objetivo, a mi, personalmente y profesionalmente, Fivewin es un producto COJONUDO!! y es el
que usamos en la empresa, para eso somos usuarios del FTDN.
Ahora , yo NUNCA he dicho que Fivewin use la tecnica del aControls, si no, que contiene el array aControls! ;-),
que es distinto, pero bien, como cada dia que pasa voy aprendiendo , hoy he aprendido realmente como funciona
EXACTAMENTE Fivewin, y te lo voy a explicar , para que me saques y nos saques de dudas: ;-)
1) En la creacion de cualquier control , en Fivewin, se llama al method ::Link().
¿ Que hace exactamente ?
Dicho method lo que hace es guardar el INDICE en el cual esta el objeto creado, dentro el array aWindows.
2) Por cada evento del sistema , se entra en la funcion _FWH(), que entre sus parametros recibe en que
indice del array aWindows, se encuentra el objeto que a generado el evento, y una vez sabiendo eso es
trivial hacer aWindows[nIndice]:HandleEvent( ... )
3) En la destruccion del objeto , Fivewin llama al method UnLink(), para desreferenciar el indice dentro
del array aWindows.
Por lo tanto, en Fivewin para Harbour , se sigue el proceso de:
1) En la creacion METHOD Create() --> METHOD Link()
2) Gestion de los eventos a traves de la funcion _FWH()
3) Destruccion METHOD Destroy() -> METHOD UnLink()
En contra posicion del sistema , llamamoles oSender:
1) Creacion METHOD Create()
2) Gestion del evento, directamente a un method() ( o ejecuccion de un codeblock, en Xailer, si se quiere )
3) Destruccion METHOD Destroy()
Es decir , a traves del oSender, no es necesario el array aControls , ni usar Ascan para encontrar la
referencia al indice para desferenciarlo, etc..., simplemente no es necesario.
Ahora bien, con ello , no estoy diciendo, ni mucho menos, que un sistema sea mejor que otro, si no, diferente,
y lo unico que me interesaba era explicar a la gente, las diferencias entre distintos GUIS y
su implementacion.
De todas, creo, tambien que el sistema que usa Fivewin, te protege y quedas mas protegido a causas externas derivado por otro tipo de problemas, tal y
como hemos hablado.
Amigo, desde hace tiempo vengo siguiendo el avance de vuestro GUI y realmente quisiera saber Donde puedo obtener vuestro gui?
Escrito por Elio Linarez a las 11 de Diciembre 2004 a las 12:11 AM