🚀 go-pugleaf

DrPanic wrote:

> On Sun, 26 Nov 2000 23:41:37 +0100, Juan Gonzalo de Silva Medina
> <gonzalo@caymasa.es> wrote:
> 
> 
>[...] 
> 
> No necesito saberlo, en mi arbol siempre que se pulsa con el rat�n se
> selecciona un mensaje, aunque adem�s se abra o se cierre. Ya te digo
> que mi arbol es muy especifico para mi problema, no tengo tiempo de
> ponerme a hacer un arbol gen�rico, adem�s si MS se decide a soportar
> de una vez swing es su navegador dentro de algo de tiempo no har�
> falta ;-) esperemos.
> 

�Seguro? eso puede ser casi milagroso... veamos, para ello tu arbol ha 
de ocupar todo el cambas, o sea, que si pincha en un espacio en blanco a 
la derecha de un texto, tu has de considerar que ha pulsado el texto.

Yo no estoy diciendo que pongas un arbol gen�rico, siento si me he 
explicado mal.

 
>> Si haces que el applet sea mouse-listener del canvas solo obtendr�s la 
>> pulsaci�n del rat�n, pero no sabr�s qu� es lo que se est� pulsando o 
>> bien, tendr�s que pasar la complejidad de esto al applet para que �l lo 
>> investigue, cosa que no me parece muy correcta...
> 
> 
> Siempre puedes tener una variable en la que el applet pueda el tipo de
> evento que ha ocurrido. O sea, el applet dice, han pulsado, voy a ver
> lo que ha pasado.
> 

AH! ahora, ya ha aparecido el motivo... o sea, reaprovechas el evento de 
pulsaci�n de rat�n, no para que extrictamente el applet lo escuche y 
actue mirando que se est� pulsando en tu cambas (mirando el evento de 
pulsaci�n) sino que ha de mirar una variable (o llamar un m�todo, para 
los puristas) para saber que ha ocurrido.

 
> 
>> Por supuesto que siempre es necesario dejar pasar el evento con 
>> super.processMouseEvent(e);
> 
> 
> Pero si dejas pasar el evento no tiene sentido tu soluci�n al
> problema, porque por un lado el applet est� atendiendo a eventos del
> tipo de AWT (mouse Event y todos esos) y por el otro atiende a eventos
> del tipo que tu creas como nodoAbierto, etc. lo cual no tiene l�gica.
> Yo en tu soluci�n no pasar�a los eventos AWT y los transformar�a en el
> otro tipo de eventos.
> 

Ojo, creo que he vuelto ha explicarme mal, lo que yo te digo es que el 
evento lo has de pasar al padre con super, ya que este realiza cosas, si 
es necesario, solo se ha de consumir el evento cuando se tenga claro que 
no hay que seguir proces�ndolo, pero como regla general se debe de 
llamar al padre (y en primer lugar en vez de en �ltimo lugar). Esto es 
la regla general de la construcci�n de controles propiertarios en AWT (y 
en Swing, claro). Aunque en tu caso poco importa, ya que un cambas no 
hace nada con el click.

 
>> Pero sigo pensando que tienes que hacer la notificaci�n que te interese.
>> 
>> Tu dir�s...
> 
> 
> A mi como lo he hecho ahora me funciona, no complicas el esquema de
> clases y adem�s es la soluci�n propuesta por sun, no lo voy a tocar,
> no me merece la pena, pero si, estoy de acuerdo contigo en que tu
> sistema ser�a mucho mas "de alto nivel", pero AWT es AWT quiz� el
> sistema de eventos de AWT entero est� mal planteado, �como es el de
> swing?
> 
> PD. Me gustan estas discusiones de arquitectura, se pone interesante.

Uf, el sistema de evento de AWT ha sido modificado por lo menos de la 
1.0 a la 1.1 (en este mismo grupo, hace tiempo, se advertia de esto ;-) 
), de echo tu no miras el click de checkButton (no te haces 
mouseListener) sino que miras sus eventos expec�ficos.

Perdona, pero no se de donde has sacado eso de que la soluci�n propuesta 
por Sun es hacer mouse-listener y pasar un estado a trav�s de una 
variable, para saber que ha ocurrido. Yo en el api de AWT no he visto 
nada as� (salvo en los cambas puros y duros, claro).

Lo que si hace Sun es definir cierto grupo de Eventos comunes a todos 
sus componentes como ActionListener, ya que casi todos los controles 
visuales pueden genera el evento de ActionPerformed. Esto lo hace para 
simplificar el esquema de escuchadores y no hacerte tener muchos m�todos 
distintos (varios ActionPerformed espec�ficos). Pero esto siempre es 
discutible, ya que finalmente, dentro de tu c�digo tendr�s que preguntar 
por el objeto o por la clase de objeto que ha realizado el evento...


Saludos,

P.S.: Voy de viaje hasta el mi�coles no podr� seguir este tema.. :(

--
Juan Gonzalo de Silva Medina
if(!Linux) throw new Exception(" :( ");