🚀 go-pugleaf

On Tue, 28 Nov 2000 01:00:55 +0100, Juan Gonzalo de Silva Medina
<gonzalo@caymasa.es> wrote:


>�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.

No hay espacio blanco, mi arbol es como el de el Agent es una especie
de tabla-arbol con tres columnas, Titulo del mensaje, Autor y Fecha.


>> 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.

Ya te digo que no es mi caso porque un click siempre produce el mismo
efecto: se selecciona otro mensaje y puede ser que se habra un nodo
adem�s, pero eso al applet le trae sin ciudado porque solo le interesa
saber que mensaje est� seleccionado.
Pero bueno, si tubiera que diferenciar eventos me parece que lo de la
variable es una buena soluci�n no le veo problemas.
 

>
>> 
>> 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). 

�Llamar al padre lo primero? Pues eso no lo he visto en ning�n lado de
hecho en la documentaci�n viene un ejemplo y lo llama al final. Date
cuenta que si llamas al padre el primero una de las funciones de ese
m�todo es pasar el evento a todos los que se han a�adido como
listeners y es posible que eso no te venga bien porque todav�a no has
hecho tengas que hacer en tu control.

>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.

Pasar el evento a todos los listeners que ya es.
 

>> 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.

�Expec�ficos?, pero si en AWT 1.1 los �nicos eventos que hay son: 
action  adjustment  component  container  focus  item  key  mouse
mouse motion  text  window �O me estabas hablando de Swing? Es que me
he liao me parece ;-)  

>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).

Haber, en la documentaci�n del Java 2 SKD, en la secci�n Guide to
Features - Java Platform dentro de AWT pulsas en Overview of Previous
Enhancements en Delegation Event Model  y en la secci�n Handling
Events in Extended Components.
Hombre, normalmente si vas a crear un componente lo haces a partir de
canvas, porque por ejemplo a un bot�n no se le puede cambiar el look
para ponerle un dibujo en vez de un texto (en AWT 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...

Pero actionEvent solo lo genera button, list, menuItem y textField,
podr�a haber usado actionEvent en vez de MouseEvent, pero canvas no
genera action events y hubiera necesitado implementar la interface
para "traducir" un evento a otro.


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

�Que aproveche el viaje! Por cierto, cuando escriba la memoria del
proyecto te pego un toque, que con lo que me estas ayudando te has
ganado un puesto de honor en la secci�n de agradecimientos :-)