Alaska Software Inc. - Manejo de Eventos en el ABM-GUI
Username: Password:
AuthorTopic: Manejo de Eventos en el ABM-GUI
Jose Luis OterminManejo de Eventos en el ABM-GUI
on Tue, 30 Nov 2010 01:46:51 -0300
Estimados Colegas,

S que estn esperando la continuacin del ABM genrico.
Ya he visto las colaboraciones de Pablo Botella (aun no lo he probado, 
chaval ), de Gustavo Burgos y Jorge Borlando.
En honor a la verdad, aplaudo los esfuerzos que le han dedicado a aprender 
Xbase++ y agradezco la valenta de exponer sus fuentes a la crtica adems 
de compartirlos desinteresadamente.

Ahora debo regresar a nuestro proyecto de ABM.
Para los colegas que nos siguen y no hablan espaol:
ABM = Altas (New Record)
            Bajas (Delete Record)
            Modificaciones (Update Record).

Hemos visto que el usuario puede generar un hilo de ejecucin diferente del 
que hemos pensado.
No slo so, tambin puede ejecutar la misma accin con diferentes recursos: 
Teclado o ratn. Men o Botn.
Por ese motivo ya no es vlido el esquema que hemos visto publicado en el 
hilo anterior.
Luego de discutir en este hilo sobre cmo resolver el hilo de ejecucin, 
actualizar el proyecto inicial.

Mientras tanto, me gustara saber qu solucin se propone para el dilema:

a) El usuario desea producir un Alta desde Men.
b) El usuario desea producir un Alta desde un Botn en la Barra de 
Herramientas (ToolBar).
c) El usuario desea producir un Alta con la combinacin de teclas Ctrl+N 
(Nuevo Registro).

Espero sugerencias.

Jos Luis Otermin
Alaska Software
Soporte Tcnico
--------------------------------------------------------------------
Foros de Usuarios: news://news.alaska-software.com
Pgina Web: http://www.alaska-software.com
Base de Conocimientos en la Web: http://www.alaska-software.com/kbase.shtm
Oficina en Europa: Fax: +49 (0) 61 96 - 77 99 99 23
Oficina en EEUU: Fax: +1 (646) 218 1281
--------------------------------------------------------------------







-- 
Jos Luis Otermin
Alaska Software
Soporte Tcnico
--------------------------------------------------------------------
Foros de Usuarios: news://news.alaska-software.com
Pgina Web: http://www.alaska-software.com
Base de Conocimientos en la Web: http://www.alaska-software.com/kbase.shtm
Oficina en Europa: Fax: +49 (0) 61 96 - 77 99 99 23
Oficina en EEUU: Fax: +1 (646) 218 1281
--------------------------------------------------------------------
Pablo BotellaRe: Manejo de Eventos en el ABM-GUI
on Tue, 30 Nov 2010 10:57:51 +0100
Hola,

> Ya he visto las colaboraciones de Pablo Botella 
>(aun no lo he probado, chaval )
Pues ya tardas <ggg>

> Luego de discutir en este hilo sobre cómo resolver el hilo de ejecución, 
> actualizaré el proyecto inicial.
Antes de seguir yo me pararía a discutir el bucle de eventos, porque el resto del codigo de nuestra aplicación va a estar condicionado por la manera en que resolvamos el manejo de los eventos.

Para mi el bucle de eventos ideal se tiene que parecer mucho a esto:

while evt != nExitEvent   normalmente xbeP_Quit o xbeP_Close
   evt := AppEvent(@p1,@p2,@xbp)
   xbp:HandleEvent(evt,p1,p2)
end

cualquier cosa extra entre el while y el end estaría de sobra

La idea es que cada objeto xbp ( cualquier objeto derivado de XbpPartHandler) maneje sus propios eventos, normalmente tendremos "callbacks" keyboard, close, enter,leave,... donde poder alojar un codeblock que maneje los eventos segun nuestras necesidades

Ademas de poder alojar codeblocks tambien podemos redefinir estos métodos en nuestras clases derivadas para decidir en que momento insertamos nuestro codigo

CLASS MiXbp FROM XbpLoQueSea
EXPORTED:
INLINE METHOD keyboard( nKeyCode )
   if nKeyCode == codigo_de_la_tecla_que_queramos
       ....hacemos lo que necesitemos
      return Self
   end
   return ::XbpLoQueSea:Keyboard(nKeyCode)
ENDCLASS

Asimismo podemos responder a otros eventos redefiniendo el metodo HandleEvent

#define xbeP_Canta  (xbeP_User + 1)

CLASS MiXbp FROM XbpLoQueSea
EXPORTED:
VAR canta
INLINE METHOD HandleEvent( nEvent,mp1,mp2)
   if nEvent == xbeP_Canta
      return ::Canta(mp1,mp2)
   end
   return ::XbpLoQueSea:HandleEvent(nEvent,mp1,mp2)

INLINE METHOD Canta( mp1,mp2)
   if Valtype(::canta) =="B"
      return Eval( ::canta , mp1,mp2, Self )
   end
   MsgBox("La tararaaaaa...")
   return Self
ENDCLASS

Y rizando el rizo, no es necesario que un xbp se corresponda con una ventana, podríamos usar un xbp derivando directamente de XbpPartHandler que simplemente se dedique a despachar determinados eventos


>a) El usuario desea producir un Alta desde Menú.
>b) El usuario desea producir un Alta desde un Botón en la Barra de 
>Herramientas (ToolBar).
>c) El usuario desea producir un Alta con la combinación de teclas Ctrl+N 
>(Nuevo Registro).

Pues yo manejaría los 3 casos de la misma manera haciendo PostAppEvent() al dialogo que tenga el foco
con un evento propio, cuando saque otro ratito libre pondré un ejemplo ( si no lo pone antes Jose Luis  )

Saludos,
Pablo
Jose Luis OterminRe: Manejo de Eventos en el ABM-GUI
on Tue, 30 Nov 2010 10:44:28 -0300
Hoy tenemos una discusin "jugosa".

He ledo la excelente exposicin de Pablo y me gust mucho.
Pero antes de nadar en aguas profundas, veamos el siguiente esquema adjunto.

Todo sistema basado en eventos debe tener definidos:
a) Los cdigos de eventos que sern procesados.
b) Un lugar dnde procesar los eventos generados en tiempo de ejecucin.

Por ejemplo:
a)
//-------------------------------------------------------
 Defines para acciones de ABM
//-------------------------------------------------------
#define xbeU_Altas              xbeP_User + 100
#define xbeU_Bajas              xbeP_User + 101
#define xbeU_Modificaciones     xbeP_User + 102
#define xbeU_Guardar            xbeP_User + 103

#define xbeU_Copiar             xbeP_User + 210
#define xbeU_Cortar             xbeP_User + 211
#define xbeU_Pegar              xbeP_User + 212
#define xbeU_Deshacer           xbeP_User + 213
#define xbeU_Rehacer            xbeP_User + 214
#define xbeU_Buscar             xbeP_User + 215
#define xbeU_Reemplazar         xbeP_User + 216

#define xbeU_Imprimir           xbeP_User + 300

#define xbeU_Menu               xbeP_User + 500

Si generamos eventos en los lugares apropiados, nos despreocuparemos del
lugar fsico donde se procesarn.
Sugiero aislar en una rutina apropiada el procesamiento de los eventos
generados.
b)

//////////////////////////////////////////////////////

PROCEDURE Execute( nEvent, mp1, mp2, oXbp )

//////////////////////////////////////////////////////
   DO CASE
   CASE nEvent == xbeU_Altas
   CASE nEvent == xbeU_Bajas
   CASE nEvent == xbeU_Modificaciones
   CASE nEvent == xbeU_Guardar

   CASE nEvent == xbeU_Copiar
   CASE nEvent == xbeU_Cortar
   CASE nEvent == xbeU_Pegar
   CASE nEvent == xbeU_Deshacer
   CASE nEvent == xbeU_Rehacer
   CASE nEvent == xbeU_Buscar
   CASE nEvent == xbeU_Reemplazar

   CASE nEvent == xbeU_Imprimir
   ENDCASE

RETURN

Es normal que surjan algunas dudas a partir de sto.
La finalidad de estas reflexiones es producirlas.
Me interesan las opiniones, dudas, preguntas, propuestas.
Todo contribuye a clarificar el conocimiento.

Espero haberlos motivado 


Jos Luis Otermin
Alaska Software
Soporte Tcnico
--------------------------------------------------------------------
Foros de Usuarios: news://news.alaska-software.com
Pgina Web: http://www.alaska-software.com
Base de Conocimientos en la Web: http://www.alaska-software.com/kbase.shtm
Oficina en Europa: Fax: +49 (0) 61 96 - 77 99 99 23
Oficina en EEUU: Fax: +1 (646) 218 1281
--------------------------------------------------------------------





QuienesEmitenEventos.png
Osvaldo Ramirez Re: Manejo de Eventos en el ABM-GUI
on Tue, 30 Nov 2010 08:49:32 -0700
Estimado Don gato ...

Me gusta la idea por las tres opciones, via teclado, boton y menu.

En lo particular solo uso boton y teclado, ya que via menu, mi siclo de 
eventos, me procesa doble dichos eventos via menu. ( Claro es cosa de 
buscarle )

Anexo una ventana como es que tengo un ABC.

En esa ventana los botones hace un postappevent al teclado ...
luego la misma ventana atrapamos los eventos del teclado y los 
direcciono a un procedimiento, como el que sigue:


PROCEDURE pr_fa_b( _lastkey , _request , oBrowse , oWindow, cNewValue )
* Begin

   static _charkey

   _charkey := upper( chr( _lastkey ))

   do case
     CASE _charkey = "A"  Agregar
     CASE _charkey = "M"  Modificar
     CASE _charkey = "D"  Detallar
     ....
   endcase
return


Saludos
Osvaldo Ramirez


ABC.jpg
Jose Luis OterminRe: Manejo de Eventos en el ABM-GUI
on Tue, 30 Nov 2010 23:51:58 -0300
Jelou mi cuate!

> Estimado Don gato ...
Debo darme una vuelta por Ciudad Jurez antes que te vuelvas millonario y no 
me conozcas ms 

> Me gusta la idea por las tres opciones, via teclado, boton y menu.

Bien, iremos a por todo 

> En lo particular solo uso boton y teclado, ya que via menu, mi siclo de
> eventos, me procesa doble dichos eventos via menu. ( Claro es cosa de
> buscarle )

Habria que ver cuntos eventos se generan por el efecto del "rebote".

> Anexo una ventana como es que tengo un ABC.

Est bonita.

> En esa ventana los botones hace un postappevent al teclado ...
> luego la misma ventana atrapamos los eventos del teclado y los
> direcciono a un procedimiento, como el que sigue:

Mira, si trabajas con el concepto Wi-Fi, no tendrs que preocuparte por el 
destinatario de tus mensajes, debido a que cada dispositivo de escucha 
captar los mensajes dirigidos hacia l y con ello nos desprenderemos de la 
lgica cableada (hardwired logic).

Nuestros artefactos tienen que ser autnomos en cuanto al desempeo de su 
misin y funcionales respecto del contexto donde se desenvuelven.
Por ejemplo:
La misin de un botn es mostrar un texto y aceptar "presin" sobre l.
Su funcionalidad respecto del contexto es emitir un evento que indique al 
sistema la accin que se espera a continuacin.
El sistema debe tener un lugar donde se "escuchen" los eventos generados por 
los artefactos y decidir la accin segn las indicaciones escritas.

Por supuesto que existen tantas estrategias como profesionales habemos.
Pero... hay estrategias que requieren mucho esfuerzo de manutencin.
Y estn las estrategias del "hombre vago" (mi caso) donde slo quiero 
mantener el cdigo en el mejor lugar posible:
Donde se ejecuta el programa del cliente.
Los componentes deben estar separados de la lgica de la solucin.
De esa forma los componentes sern reutilizables (lo que ms amo de la 
POO!) y nuestros problemas estarn limitados a la lgica del negocio.

> PROCEDURE pr_fa_b( _lastkey , _request , oBrowse , oWindow, cNewValue )
> * Begin
>
>   static _charkey
>
>   _charkey := upper( chr( _lastkey ))
>
>   do case
>     CASE _charkey = "A"  Agregar
>     CASE _charkey = "M"  Modificar
>     CASE _charkey = "D"  Detallar
>     ....
>   endcase
> return

La lgica sigue perfectamente lo que estamos conversando.
Sin embargo, a m me gustara usar un arreglo con valores y acciones.

Por ejemplo:

#define xbeK_A          65
#define xbeK_B          66
#define xbeK_C          67
#define xbeK_D          68
#define xbeK_E          69
#define xbeK_F          70
#define xbeK_G          71
#define xbeK_H          72
#define xbeK_I          73
#define xbeK_J          74
#define xbeK_L          76
#define xbeK_L          76
#define xbeK_M          77
#define xbeK_O          79
#define xbeK_P          80
#define xbeK_Q          81
#define xbeK_R          82
#define xbeK_S          83
#define xbeK_T          84
#define xbeK_U          85
#define xbeK_V          86
#define xbeK_W          87
#define xbeK_X          88
#define xbeK_Y          89
#define xbeK_Z          90

#define xbeK_a          97
#define xbeK_b          98
...
#define xbeK_z          122


aAcciones := Array(0)

AADD( aAcciones, { {xbeK_a, xbeK_A}, {|| Altas() } } )
AADD( aAcciones, { {xbeK_b, xbeK_B}, {|| Bajas() } } )
AADD( aAcciones, { {xbeK_d, xbeK_D}, {|| Detallar() } } )
AADD( aAcciones, { {xbeK_m, xbeK_M}, {|| Modificar() } } )

La evaluacin entonces se reducira a:

> PROCEDURE pr_fa_b( _lastkey , _request , oBrowse , oWindow, cNewValue , 
> aAcciones)
> * Begin
     nPos := ASCAN( _lastkey, aAcciones )
    IF nPos > 0
         EVAL( aAcciones[nPos] )
    ENDIF
   * End
RETURN

De esta forma slo las teclas registradas en el arreglo sern procesadas y 
por consiguiente, las acciones asociadas se ejecutarn sin problema.
Dale una mirada a ABM-GUI, es un modelo pequeo, pero sugiere la idea.
En particular, PROCEDURE DoEvents()

> Saludos
> Osvaldo Ramirez
Un abrazo grande

Jos Luis Otermin
Alaska Software
Soporte Tcnico
--------------------------------------------------------------------
Foros de Usuarios: news://news.alaska-software.com
Pgina Web: http://www.alaska-software.com
Base de Conocimientos en la Web: http://www.alaska-software.com/kbase.shtm
Oficina en Europa: Fax: +49 (0) 61 96 - 77 99 99 23
Oficina en EEUU: Fax: +1 (646) 218 1281
--------------------------------------------------------------------
Osvaldo Ramirez Re: Manejo de Eventos en el ABM-GUI
on Wed, 01 Dec 2010 11:51:43 -0700
On 11/30/2010 7:51 PM, Jose Luis Otermin wrote:
> Jelou mi cuate!
>
>> Estimado Don gato ...
> Debo darme una vuelta por Ciudad Juárez antes que te vuelvas millonario y no
> me conozcas más 
>
>> Me gusta la idea por las tres opciones, via teclado, boton y menu.
>
> Bien, iremos a por todo 
>
>> En lo particular solo uso boton y teclado, ya que via menu, mi siclo de
>> eventos, me procesa doble dichos eventos via menu. ( Claro es cosa de
>> buscarle )
>
> Habria que ver cuántos eventos se generan por el efecto del "rebote".
>
>> Anexo una ventana como es que tengo un ABC.
>
> Está bonita.
>
>> En esa ventana los botones hace un postappevent al teclado ...
>> luego la misma ventana atrapamos los eventos del teclado y los
>> direcciono a un procedimiento, como el que sigue:
>
> Mira, si trabajas con el concepto Wi-Fi, no tendrás que preocuparte por el
> destinatario de tus mensajes, debido a que cada dispositivo de escucha
> captará los mensajes dirigidos hacia él y con ello nos desprenderemos de la
> lógica cableada (hardwired logic).
>
> Nuestros artefactos tienen que ser autónomos en cuanto al desempeño de su
> misión y funcionales respecto del contexto donde se desenvuelven.
> Por ejemplo:
> La misión de un botón es mostrar un texto y aceptar "presión" sobre él.
> Su funcionalidad respecto del contexto es emitir un evento que indique al
> sistema la acción que se espera a continuación.
> El sistema debe tener un lugar donde se "escuchen" los eventos generados por
> los artefactos y decidir la acción según las indicaciones escritas.
>
> Por supuesto que existen tantas estrategias como profesionales habemos.
> Pero... hay estrategias que requieren mucho esfuerzo de manutención.
> Y están las estrategias del "hombre vago" (mi caso) donde sólo quiero
> mantener el código en el mejor lugar posible:
> Donde se ejecuta el programa del cliente.
> Los componentes deben estar separados de la lógica de la solución.
> De esa forma los componentes serán reutilizables (¡lo que más amo de la
> POO!) y nuestros problemas estarán limitados a la lógica del negocio.
>
>> PROCEDURE pr_fa_b( _lastkey , _request , oBrowse , oWindow, cNewValue )
>> * Begin
>>
>>    static _charkey
>>
>>    _charkey := upper( chr( _lastkey ))
>>
>>    do case
>>      CASE _charkey = "A"  Agregar
>>      CASE _charkey = "M"  Modificar
>>      CASE _charkey = "D"  Detallar
>>      ....
>>    endcase
>> return
>
> La lógica sigue perfectamente lo que estamos conversando.
> Sin embargo, a mí me gustaría usar un arreglo con valores y acciones.
>
> Por ejemplo:
>
> #define xbeK_A          65
> #define xbeK_B          66
> #define xbeK_C          67
> #define xbeK_D          68
> #define xbeK_E          69
> #define xbeK_F          70
> #define xbeK_G          71
> #define xbeK_H          72
> #define xbeK_I          73
> #define xbeK_J          74
> #define xbeK_L          76
> #define xbeK_L          76
> #define xbeK_M          77
> #define xbeK_O          79
> #define xbeK_P          80
> #define xbeK_Q          81
> #define xbeK_R          82
> #define xbeK_S          83
> #define xbeK_T          84
> #define xbeK_U          85
> #define xbeK_V          86
> #define xbeK_W          87
> #define xbeK_X          88
> #define xbeK_Y          89
> #define xbeK_Z          90
>
> #define xbeK_a          97
> #define xbeK_b          98
> ...
> #define xbeK_z          122
>
>
> aAcciones := Array(0)
>
> AADD( aAcciones, { {xbeK_a, xbeK_A}, {|| Altas() } } )
> AADD( aAcciones, { {xbeK_b, xbeK_B}, {|| Bajas() } } )
> AADD( aAcciones, { {xbeK_d, xbeK_D}, {|| Detallar() } } )
> AADD( aAcciones, { {xbeK_m, xbeK_M}, {|| Modificar() } } )
>
> La evaluación entonces se reduciría a:
>
>> PROCEDURE pr_fa_b( _lastkey , _request , oBrowse , oWindow, cNewValue ,
>> aAcciones)
>> * Begin
>       nPos := ASCAN( _lastkey, aAcciones )
>      IF nPos>  0
>           EVAL( aAcciones[nPos] )
>      ENDIF
>     * End
> RETURN
>
> De esta forma sólo las teclas registradas en el arreglo serán procesadas y
> por consiguiente, las acciones asociadas se ejecutarán sin problema.
> Dale una mirada a ABM-GUI, es un modelo pequeño, pero sugiere la idea.
> En particular, PROCEDURE DoEvents()
>
>> Saludos
>> Osvaldo Ramirez
> Un abrazo grande
>


La producion de los cuales son las opciones o botones a generar las hago 
en vuelo, es decir, configuro como muchos, en textos y los interpreto, 
pero tu punto de viesta es buenisimo.

El salto a OPP seria excelente!!!