2010-08-22 16 views
16

Sé que al usar este método, el parámetro ejecutable se envía al sistema EventQueue. Pero, ¿deberían hacerse todas las actualizaciones de GUI usando este método? Es decir, si yo quiero decir, cambiar un texto de JButton, debo usar algo como esto:¿Deberíamos usar EventQueue.invokeLater para cualquier actualización de GUI en una aplicación de escritorio Java?

java.awt.EventQueue.invokeLater(new Runnable() { 
     public void run() { 
     jButton1.setText("changed text"); 
     } 
}); 

si debería usar este enfoque, cualquier patrón que puede utilizar para evitar este código repetitivo?

+0

Nota: el código lento debe ir también para mantener el swing receptivo –

+4

@nash Si alguna de las siguientes respuestas responde a su pregunta, ¿podría marcarla como respondida? –

Respuesta

27

Solo necesita usar invokeLater cuando desea actualizar su UI desde otro hilo que no sea el de la interfaz de usuario (hilo de envío del evento).

Supongamos que tiene un controlador para hacer clic y desea cambiar el texto de una etiqueta cuando alguien hace clic en el botón. Entonces es perfectamente seguro para establecer el texto de la etiqueta directamente. Esto es posible porque el controlador para el evento de clic de botón se ejecuta en el subproceso de interfaz de usuario.

Supongamos, sin embargo, que con otro clic de botón inicia otro subproceso que hace algún trabajo y una vez que este trabajo finalice, desea actualizar la interfaz de usuario. Luego usa invokeLater. Este método asegura que su actualización de UI se ejecute en el subproceso de interfaz de usuario.

Por lo tanto, en muchos casos, no necesita invokeLater, simplemente puede hacer las actualizaciones de la interfaz de usuario directamente. Si no está seguro, puede usar isDispatchThread para verificar si su código actual se está ejecutando dentro de la cadena de distribución del evento.

+0

Ok, supongo que, si no estamos seguros, podemos usar el método EventQueue.isDispatchThread() para comprobar si el hilo actual es el hilo de envío del evento. ¿derecho? – nash

+1

Eso es correcto. Agregué un poco de información sobre este método a mi respuesta. –

+0

¿Pero todavía no hay atajos? Me hubiera gustado un acceso directo o una macro para la repetición estándar (si esDispatchThread do X, de lo contrario ajuste X y colóquelo). Viniendo de Delphi, me gustaría llamar a todo el asunto 'Sync (x (a, b, c))', pero supongo que con la sintaxis java como sintaxis java, el material 'public void {}' es inevitable. Es gracioso para mí que debería desear tener macros de estilo C para evitar escribir Java, ya que está diseñado para ser escrito. –

2

Debe hacer esto solo si no está ya en el hilo de envío del evento. A menos que haya iniciado nuevos hilos o ejecutado el código del hilo principal, probablemente todo su código ya se ejecute desde el hilo de envío del evento, haciendo que esto sea innecesario. Por ejemplo, todos los manejadores de eventos de UI son llamados en el hilo de envío del evento, por lo que no necesitaría hacer eso para el código llamado desde allí.

1

En lugar de evitar realmente "repetitivo" (es probable que las personas java digan, código legible sin muchos secretos) podría utilizar la función de plantillas de Eclipse. Lo tengo configurado para expandir las dos letras "il" para el bloque siguiente:

EventQueue.invokeLater(new Runnable() { 
      public void run() { 
       try { 
        // do something. 
       } catch (Exception e) { 
        e.printStackTrace(); 
       } 
      } 
     }); 

Al parecer, este diseño de cola de distribución no sólo se recomienda, es básicamente necesario. Esta es quizás la forma más ruidosa que he visto en cualquier idioma de enviar una lambda a una cola de mensajes. Pero ahí está. Esto es java Y en defensa de Java, desde luego, es obvio lo que está sucediendo exactamente. Me molesta la cantidad de tipeo, pero lo único que puedo pensar que evitaría es el preprocesador Mac, y apuesto a que a la gente de Java no le gusta usar eso. La expansión de código a través de plantillas es más legible, compatible y no implica magia negra.

+0

P no, no, nunca use try - catch - finalmente para construir la GUI, ni dentro de invokeLater :-) – mKorbel

+1

@mKorbel ¿Puede explicar por qué? – varuog

+1

Creo que no tiene otra opción para las excepciones marcadas. –

Cuestiones relacionadas