🚀 go-pugleaf

On 10 abr, 14:57, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
wrote:
> ...
> Esto funciona bien si salgo del campo pulsando [Tab] (lo que me lleva
> a un JButton que hay debajo del campo de texto). Mi problema surge si,
> mientras tengo el foco en el campo de texto, hago clic en otro nodo
> del árbol. En este caso, TreeValueChanged se ejecuta *antes* de
> LocusFost (lo cual no encuentro lógico; primero se pierde el foco del
> campo de texto y sólo entonces puede cambiar el valor del nodo
> seleccionado en el árbol, EMO).
>
> Por más que busco, no he podido encontrar ningún documento que indique
> la prioridad con la que se ejecutan los eventos. He buscado este mismo
> problema en Internet, en los tutoriales de Java, en los archivos de
> foros y listas de correo, y en la documentación de JavaHispano.org
> (*), y no he encontrado nada. Si alguien puede ayudarme a variar el
> comportamiento, o bien explicarme por qué estoy equivocado al pensar
> que primero se debe perder el foco de un control y luego ganarlo en
> otro, le estaré muy agradecido. :-)

Hola Ricardo,

En los viejos manuales de VB, te encontrabas con frecuencia
advertencias de que no podias asumir un orden particular en los
eventos. Luego llego VB6 con su "Validate", y nos simplifico un poco
la vida. Antes de Validate, tanto las validaciones como el proceso del
efecto de los cambios habia que hacerlos en LostFocus, y era una
pu*ada, ya que si a consecuencia de un fallo de validacion tenias que
traer el foco de regreso al control en proceso, disparabas el
LostFocus de quienquiera que lo hubiese recibido a consecuencia de la
accion que disparo el LostFocus original. Algo parecido es lo que te
ocurre (pero eso sin duda ya lo sabes).

Imagino que -a falta de algo parecido a validate (recorri buena parte
de la documentacion de Swing sin encontrar nada)= no nos quedara mas
remedio que trabajar con "contextos".

En tu caso, lo minimo seria un indicador (boolean isDirty;) que dice
que el JTextField de la derecha ha sido modificado (en el
DocumentListener: que perversos pueden ser los lenguajes). En el
LostFocus, si isDirty, procesas el cambio. Pero en el TreeValueChanged
verificas el estado de isDirty y actualizas lo que tengas que
actualizar antes de procesar efectivamente el evento. En ese proceso
de los cambios, restableces isDirty a false. Pero esto ya lo
sabias :-)

En la documentacion de Swing hay una seccion que describe el "AWT
Focus Subsystem" donde queda claro que primero se procesa la
activacion del componente que recibe el foco y luego la perdida del
foco del componente que lo entrega.

Aparentemente la torpeza en el manejo de los eventos tiene que ver con
las limitaciones que impone la independencia de plataforma (al menos
eso dicen ellos).

Habra que volver a las viejas cochinerias.


Salud!