Propagación de Eventos

En 3.1.3 fueron identificados varios eventos de interés. Estamos en condiciones ahora de ver el mecanismo completo de propagación de eventos y para fijar ideas se han elegido un par de casos representativos en sintonía con la categorización antes mencionada. Comenzaremos con un ejemplo sencillo en el cual el evento en cuestión no está asociado a un cambio de estado:

Ejemplo: bicotiActorGraphic2DPushButton - Explicaremos en detalle el funcionamiento de este actor y la relación con sus clases auxiliares. En Fig.14 puede verse un esquema de todas las entidades involucradas en este proceso.

Figure 14: Funcionamiento del bicotiActorGraphic2DPushButton

Diferenciaremos dos situaciones que resumen el comportamiento:

En el primer caso un actor sin homólogo asociado recibe la orden Click() desde alguna parte de la aplicación y en consecuencia dispara el correspondiente PushButtonClicked() con un puntero a si mismo a cada uno de sus listeners.

Figure 15: Click sin homólogo

Distinta es la situación en que existe el homólogo del actor, el event loop está activo y un usuario clickea el botón. En este caso el homólogo captura el evento de la biblioteca gráfica e indica al actor que dispare el PushButtonClicked().

Figure 16: Click externo

Ejemplo: bicotiActorGraphic2DField - Explicaremos ahora un caso algo más complejo. A diferencia del ejemplo anterior, en un Text Field, la interacción puede cambiar el estado del actor.

Figure 17: Funcionamiento del bicotiActorGraphic2DField

Son ahora tres las situaciones destacables:

Al igual que en el ejemplo previo comenzaremos por estudiar el caso en que el actor no tiene homólogo asociado y recibe de la aplicación un SetText(). Al no tener homólogo el SetText() invoca al FireFieldChanged() con un puntero a si mismo y el nuevo texto. Si este texto no coincide con el actual, se cambia efectivamente y se notifica a todos los listeners del cambio.

Figure 18: SetText sin homólogo

Nuevamente al igual que en el ejemplo previo, veremos la secuencia desencadenada por un operador que altera el texto sobre el homólogo de un bicotiActorGraphic2DField. En este caso, cada vez que el operador agrega un caracter al text field, se invoca un FireFieldChanged(), que al igual que en el caso anterior termina notificando a todos los listeners del cambio. Cabe destacar que aunque lo natural en este último caso parecería ser que el homólogo invocara un SetText en el actor, esto generaría una recursión infinita dado el comportamiento de este método, que se verá a continuación. Este diagrama de interacción puede verse en Fig.19.

Figure 19: Cambio de texto externo

Solo resta ver que sucede si desde la aplicación, se invoca un SetText() sobre un actor con homólogo. Remarcamos en este punto que siempre es el actor el que guarda su información de estado, aún cuando tenga homólogo. Es importante por lo tanto que esta información esté siempre sincronizada. En este caso particular el texto debe cambiarse en ambos objetos (actor y homólogo) y eso es exactamente lo que sucede. En efecto el actor, al ver que tiene homólogo no dispara el fire, en su lugar redirecciona el SetText() al homólogo. Este recibe y procesa el evento del mismo modo que si hubiera venido del operador logrando el resultado deseado.

Figure 20: SetText con homólogo