Author | Topic: Manejo de Eventos en el ABM-GUI | |
---|---|---|
Jose Luis Otermin | Manejo 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 Botella | Re: 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 Otermin | Re: 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 Otermin | Re: 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!!! |