21
Aprender a programar desde cero / Re: java swing ventana gráfica
« en: 02 de Octubre 2022, 20:57 »
Hola y gracias de nuevo. He mirado lo que dice el api de Java sobre SwingUtilities.invokeLater y veo que dice
Con lo que has indicado lo entenderia así: si lo creamos con
La ejecución de las instrucciones de creación - gestión de la ventana gráfica quedan dentro del hilo principal de la aplicación y puede ocurrir lo que tú comentabas: que si en un momento dado es necesario un redibujado pero el hilo principal está entretenido en un proceso que lo ocupa, no se produce el redibujado sino que la interfaz gráfica se queda congelada hasta que se concluye lo que esta ocupando al hilo principal.
De la otra manera la interfaz grafica va dentro de un hilo independiente de despacho de eventos donde un posible redibujado se produciria despues de que todos los eventos en cola hayan sido gestionados pero de forma independiente respecto al hilo principal con lo cual si este esta entretenido los demas hilos asincronos no se quedan bloqueados.
Y me imagino que aun habria otra manera de plantear esto, que seria no tenerlo ni en el hilo principal ni en el hilo de despacho de eventos, sino en un nuevo hilo que podriamos crear independiente de estos dos.
Todo esto no lo veo sencillo, pero no se si podriamos decir que mas o menos la idea seria esta.
Citar
public static void invokeLater(Runnable doRun)
Causes doRun.run() to be executed asynchronously on the AWT event dispatching thread. This will happen after all pending AWT events have been processed. This method should be used when an application thread needs to update the GUI. In the following example the invokeLater call queues the Runnable object doHelloWorld on the event dispatching thread and then prints a message.
Runnable doHelloWorld = new Runnable() {
public void run() {
System.out.println("Hello World on " + Thread.currentThread());
}
};
SwingUtilities.invokeLater(doHelloWorld);
System.out.println("This might well be displayed before the other message.");
If invokeLater is called from the event dispatching thread -- for example, from a JButton's ActionListener -- the doRun.run() will still be deferred until all pending events have been processed. Note that if the doRun.run() throws an uncaught exception the event dispatching thread will unwind (not the current thread).
Additional documentation and examples for this method can be found in Concurrency in Swing.
As of 1.3 this method is just a cover for java.awt.EventQueue.invokeLater().
Unlike the rest of Swing, this method can be invoked from any thread.
See Also:
invokeAndWait(java.lang.Runnable)
Con lo que has indicado lo entenderia así: si lo creamos con
Código: [Seleccionar]
public static void main(String[] args) {
new Main();
}
La ejecución de las instrucciones de creación - gestión de la ventana gráfica quedan dentro del hilo principal de la aplicación y puede ocurrir lo que tú comentabas: que si en un momento dado es necesario un redibujado pero el hilo principal está entretenido en un proceso que lo ocupa, no se produce el redibujado sino que la interfaz gráfica se queda congelada hasta que se concluye lo que esta ocupando al hilo principal.
De la otra manera la interfaz grafica va dentro de un hilo independiente de despacho de eventos donde un posible redibujado se produciria despues de que todos los eventos en cola hayan sido gestionados pero de forma independiente respecto al hilo principal con lo cual si este esta entretenido los demas hilos asincronos no se quedan bloqueados.
Y me imagino que aun habria otra manera de plantear esto, que seria no tenerlo ni en el hilo principal ni en el hilo de despacho de eventos, sino en un nuevo hilo que podriamos crear independiente de estos dos.
Todo esto no lo veo sencillo, pero no se si podriamos decir que mas o menos la idea seria esta.