Discussion :

[visiwi]

Bonjour,

Je voudrais des expliquations sur l'EDT et la manière de faire des menus non bloquant. J'ai lu le très interressant tutoriel Threads et performance avec Swing de Romain Guy, mais je le trouve trop succinct.

J'ai un cas concret que je n'arrive pas a comprendre :

Voila, j'ai un AbstractAction qui me permet de gérer l'affichage d'une fenêtre permettant de paramétrer mon appli. Cette action est associé a un JMenuItem et un JButton d'une JToolBar. EcranPreferences est un JDialog modal, le paramètre ecran du constructeur est la fenêtre principale de l'appli.

Voici le code de actionPerformed :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public void actionPerformed(ActionEvent e) {
	System.out.println("EDT: "+SwingUtilities.isEventDispatchThread());
        EcranPreferences ecranPref = new EcranPreferences(ecran);
	ecranPref.setLocationRelativeTo(null);
	ecranPref.setVisible(true);
}

D'après ce que j'ai compris du tutoriel, le code qui gère de l'affichage graphique (a l'exception d'un repaint ou revalidate qui sont thread-safe) doit s'exécuté dans l'EDT. Or ici SwingUtilities.isEventDispatchThread() indique true, donc ce code est éxécuté dans l'EDT. Pourtant le bouton ou l'item du menu est bloqué (et l'appli). Pourquoi ?

Je dois éxécuter le code dans un Thread pour que le comportement ne soit plus bloquant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
public void actionPerformed(ActionEvent e) {
	final Thread th = new Thread(new Runnable() {
		public void run() {
	        	System.out.println("EDT: "+SwingUtilities.isEventDispatchThread());
		        EcranPreferences ecranPref = new EcranPreferences(ecran);
			ecranPref.setLocationRelativeTo(null);
			ecranPref.setVisible(true);
	        }
	});
	th.start();
}

Mais alors SwingUtilities.isEventDispatchThread() indique false, donc le code n'est plus exécuté dans l'EDT mais dans le Thread que je viens de créer. Pourtant cela fonctionne tel que je le souhaiterais. Pourquoi ?

Si j'ajoute un invokeLater dans le Thread pour que le code s'éxécute dans l'EDT, cela est de nouveau bloquant. Pourtant, SwingUtilities.isEventDispatchThread() indique true, donc ce code est éxécuté dans l'EDT.

Pourquoi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public void actionPerformed(ActionEvent e) {
	final Thread th = new Thread(new Runnable() {
		public void run() {
	            	EventQueue.invokeLater(new Runnable() {
	         		public void run() {
	            			System.out.println("EDT: "+SwingUtilities.isEventDispatchThread());
	    		        	EcranPreferences ecranPref = new EcranPreferences(ecran);
	    				ecranPref.setLocationRelativeTo(null);
	    				ecranPref.setVisible(true);
            			}
            		});
            	}
        });
	th.start();
}

Enfin, qu'est-ce que l'on doit mettre dans l'EDT, qu'est que l'on ne doit pas mettre ? Comment savoir que telle méthode doit être exécutée dans l'EDT et que tel autre ne doit pas l'être ? Tout cela semble clair en théorie, mais en pratique c'est assez déconcertant !

Un peu d'aide et de transfert d'expérience ne serait pas de refus

[gifffftane]

Je pense que tes problèmes viennent de la modalité de ta boite de dialogue. Je ne suis pas très à l'aise avec cette notion, et j'ai l'impression que Java non plus. Java 6 ajoute de nouvelles fonctions et corrections de bug sur ce sujet, et j'ai l'impression qu'il y en avait bien besoin.

Je m'étonne tout de même du comportement que tu relates, car j'ai moi même lancé diverses boîtes de dialogue, et je n'ai pas le souvenir que cela bloquait la fenêtre principale, sauf de façon normale puisque il y a une boite de dialogue modale ?... J'ai observé que les problèmes apparaissent souvent quand une boite de dialogue modale lance une autre boite de dialogue modale, ce qui n'est pas ton cas, et ce qui est de toutes façons de la mauvaise programmation.

Par contre, la suite du traitement n'est exécuté qu'après la fermeture de la fenêtre, c'est peut être ça qui coince : tout ce qui est après setVisible(true) ne sera exécuté qu'après un setVisible(false) de cette fenêtre modale.

Quand est-ce que ça marche en dehors du EDT ? Quand tu as du bol.

Qu'est-ce qu'il faut utiliser dans le EDT ? Tous les appels qui concernent swing... Je ne vois pas ce qu'il y a d'imprécis là dedans ?

[visiwi]

D'accord.

Ne serait-il possible que cela vienne d'une mauvaise programmation à l'intérieur de mon objet EcranPreferences ?

J'ai observé que les problèmes apparaissent souvent quand une boite de dialogue modale lance une autre boite de dialogue modale, ce qui n'est pas ton cas, et ce qui est de toutes façons de la mauvaise programmation.

Pourquoi dit-tu que c'est de la mauvaise prog ?

[gifffftane]

Cela peut venir d'une mauvaise programmation de ta classe EcranPreferences, tout est possible. Sur ce coup là il y a peu de chance, mais tout est possible. J'ai plutôt l'impression que tu fais le setVisible(true) un peu trop tôt. Mais les problèmes de modalités peuvent être pénibles.

Je trouve que d'enchainer les fenêtres modales les unes à la suite des autres est l'indice d'une mauvaise GUI, plutot qu'une mauvaise programmation, comme je l'avais dit trop rapidement. Au fond on peut faire une bonne programmation d'une mauvaise GUI.

Lorsque on doit enchainer les saisies de saisies qui s'imbriquent, je trouve que le système du wizard et mieux. Au moins l'utilisateur n'a qu'une fenêtre, et c'est beaucoup plus facile de lui indiquer où il en est. Et c'est plus facile de bien programmer aussi.

[visiwi]

J'ai plutôt l'impression que tu fais le setVisible(true) un peu trop tôt.

Qu'entends-tu par là ?

[gifffftane]

Ben tu dis je crois que les boutons restent enfoncés. Je ne sais pas trop à quel moment ils se libèrent dans le code swing, mais, comme tu lances ta fenêtre modale dans la réponse à l'évènement, si les boutons sont libérés après, ils se désenfonceront que lorsque la fenêtre modale sera fermée.

Normalement, dans la config où tu lances ta fenêtre modale dans un invokeLater, les boutons devraient être désenfoncés tout de suite, je veux dire avant l'apparition de ta fenêtre modale. Que ton appli soit bloquée vient d'autre chose.

[visiwi]

Ok.

Cela dit, j'ai essayé avec une simple JFrame sans rien dedans (et donc qui n'est pas modal) avec juste un Thread.sleep(int) pour simuler un traitement et j'ai le même comportement !! Cela ne vient donc ni du fait que la fenêtre est modal ou bien encore de la construction de EcranPreferences.

Mais il y a quand même quelques "bizarreries", quand j'appel cet écran via le JmenuItem, le menu s'efface bien, mais je ne peux pas accéder au menu le temps que la frame apparaisse. Par contre le bouton de la JToolBar reste enfoncé lorsque c'est par lui que j'appel l'écran !

Et ca n'explique toujours pas pourquoi quand je le lance à partir d'un thread, j'obtient bien le comportement que je souhaite (non bloquant) alors qu'il n'ai pas dans l'EDT.

Bon je vais chercher, en tout cas merci bien gifffftane.

[visiwi]

Voila la solution !

Je ne l'avais pas mentionné car je ne pensais pas que cela est de l'importance, mais j'avais un setEnabled(false) en début de code, et un a true en fin de code. C'est cela qui posais problème.
Donc à l'origine j'avais écrit ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
public void actionPerformed(ActionEvent e) {
	setEnabled(false);
	EcranPreferences ecranPref = new EcranPreferences(ecran);
	ecranPref.pack();
	ecranPref.setLocationRelativeTo(null);
	ecranPref.setVisible(true);
	setEnabled(true);
}

Voici ce qu'il faut écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
public void actionPerformed(ActionEvent e) {
	final Thread th = new Thread(new Runnable() {
		public void run() {
	            	try {
	            		EventQueue.invokeAndWait(new Runnable() {
	            			public void run() {
	            				setEnabled(false);
	            			}
	            		});
	            	} catch (InterruptedException ex1) {
	            		ex1.printStackTrace();
	            	} catch (InvocationTargetException ex2) {
	            		ex2.printStackTrace();
	            	}
			EventQueue.invokeLater(new Runnable() {
				public void run() {
					EcranPreferences ecranPref = new EcranPreferences(ecran);
					ecranPref.pack();
					ecranPref.setLocationRelativeTo(null);
					ecranPref.setVisible(true);
					setEnabled(true);
				}
			});
		}
	});
	th.start();	
}

Là plus rien n'est bloquant, et la règle d'unicité est respecté.

Ouf !!!!!
Merci bien pour votre aide.