🚀 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!

clearlight@cantv.net escribió:
> Hola Ricardo,


No sé por qué, pero me imaginaba que ibas a tardar muy poco en
enseñarme a mí sobre Java... Lo que no creía es que fuera a ser TAN
poco tiempo. :-)


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


Tendré que hacerlo así, pero realmente creía que había un problema en
el orden de proceso de los eventos (y ahora estoy seguro de ello).


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


En realidad no, la documentación, imagino que te refieres a ésta:

http://java.sun.com/javase/6/docs/api/java/awt/doc-files/FocusSpec.html#FocusEventAndWindowEvent

es un pelín confusa y puede interpretarse como lo has hecho, pero lo
que quiere decir esa lista es que, en un control dado que pueda
recibir el foco, el que lo consiga supone que se ejecutará primero el
evento de activación de la ventana (si procede), el de ventana que
gana el foco (si procede), luego el del evento ganando el foco, y sólo
después de haber recibido el foco podrá perderlo, y si además el foco
va a otra ventana, perderá el foco la ventana y quedará desactivada.

Justo debajo de esa lista, en "Event Delivery", hay dos ejemplos, el
segundo de los cuales ilustra que primero pierde el foco el control
que lo tenía hasta ese momento (y con él, la ventana) y sólo después
lo ganan primero la nueva ventana y luego el nuevo control.

Así que aplicaré las viejas cochinerías que me sugieres (muchas
gracias) y preguntaré en la lista en inglés de NetBeans si esto debe
ser considerado un bug de Java.

Muchas gracias de nuevo.

-- 
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

On 11 abr, 05:36, Ricardo Palomares Martinez <rpm.PU...@iespana.es>
wrote:

> No sé por qué, pero me imaginaba que ibas a tardar muy poco en
> enseñarme a mí sobre Java... Lo que no creía es que fuera a ser TAN
> poco tiempo. :-)

Son solo tiros de salva... Aun tengo todo por aprender.

> > 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.
>
> En realidad no, la documentación, ... es un pelín confusa y puede
> interpretarse como lo has hecho

Sobre todo cuando se la consulta apresuradamente despues de un dia
duro.

Habia interpretado la lista inmediatamente antes de Focus Delivery
(Focus Event and WindowsEvent) como una secuencia de eventos, y es
solo una lista.

> Así que aplicaré las viejas cochinerías que me sugieres (muchas
> gracias) y preguntaré en la lista en inglés de NetBeans si esto debe
> ser considerado un bug de Java.

Ahora me parece que si.

Y cuidado si a estas alturas, la ausencia de un evento Validate no
debiera ser considerada un bug.

Salud!

Hola,

Hay algo parecido a Validate, el InputVerifier
[Component.setInputVerifier(InputVerifier inputVerifier)] que te
permite validar ANTES de la perdida del foco. La clase (no es una
interfaz) implementa tambien un metodo [shouldYieldFocus(JComponent
input)] que te permite decidir si el foco se entrega al componente que
lo reclama, o si se conserva dentro del componente activo.

Los JComponent tienen el metodo
setVerifyInputWhenFocusTarget(boolean), que te permite indicar si el
componente activo para el momento en que "este" reciba el foco deberan
ser validados. Sirve, por ejemplo, para no validar las operaciones al
pulsar el boton de cerrar un Frame (en terminos de VB6, es equivalente
a la propiedad CausesValidation de los controles).

Ambos funcionan "pobremente" cuando te mueves a diferentes niveles de
la jerarquia de contenedores (por ejemplo, tienes un JPanel dentro de
un JTabbedPane dentro de un JFrame, y pulsas un menu en el JFrame,
donde has indicado que no se active la validacion, pero la validacion
igual se activa).

Igual eso te sirve.

Salud!