Gérer le ré-affichage d'une JList dynamique

Version imprimable

04/11/2009, 08h32
zorglubpok

Gérer le ré-affichage d'une JList dynamique

Bonjour à tous.

Je développe une IHM en Swing, assez simple (pas beaucoup de composants: un textfied, 2 boutons, une textArea et une Jlist permettant de sélectionner un élément).

Mon problème est le suivant: le contenu de la Jlist qui va être affiché est dynamique : un thread va périodiquement ajouter ou retirer des éléments de cette liste. Je souhaite donc qu'à chaque modification du contenu de la liste, le copmposant JList soit ré-affiché sur mon IHM avec le nouvel ensemble d'élèments.

Je n'ai vu aucun exemple de code java permettant de ré-afficher dynamiquement un composant comme JList. Savez-vous si ce que je souhaite faire est réalisable ? Si oui, pouvez-vous m'en indiquer les grandes lignes, svp ?
04/11/2009, 10h16
fr1man

Utilise les méthodes du model de ta JList, en l'occurrence DefaultListModel, si tu as le model par défaut:
add, addElement, remove, fireIntervalAdded, fireContentsChanged...

Fais attention à modifier ta JList dans l'EDT et non pas dans ton thread de mise à jour.
04/11/2009, 10h28
zorglubpok

Citation:

Envoyé par fr1man

Utilise les méthodes du model de ta JList, en l'occurrence DefaultListModel, si tu as le model par défaut:
add, addElement, remove, fireIntervalAdded, fireContentsChanged...

Fais attention à modifier ta JList dans l'EDT et non pas dans ton thread de mise à jour.

Quand je fais appel à addElement (par ex.), la JList sera automatiquement ré-affichée dans mon IHM ? Pas besoin de faire appel à des méthodes comme repaint() ?
Je ne suis pas très calé en IHM java, donc ma question est peut-être saugrenue, mais la solution que tu proposes fr1man me surprend ...
04/11/2009, 10h35
fr1man

Pas besoin de repaint.

Si tu ne connais pas l'EDT, tu peux lire cet article:
http://gfx.developpez.com/tutoriel/j...ing-threading/

Tu peux également regarder la classe Swingworker.
04/11/2009, 10h40
zorglubpok

Citation:

Envoyé par fr1man

Pas besoin de repaint.

Si tu ne connais pas l'EDT, tu peux lire cet article:
http://gfx.developpez.com/tutoriel/j...ing-threading/

Tu peux également regarder la classe Swingworker.

Merci, je regarde :D

Salut,

Citation:

Envoyé par zorglubpok

Quand je fais appel à addElement (par ex.), la JList sera automatiquement ré-affichée dans mon IHM ? Pas besoin de faire appel à des méthodes comme repaint() ?

Oui c'est tout à fait cela !

Lorsque tu ajoutes un éléments dans ton modèle, il va générer un évènement qui va signaler les modifications au composant, et ce dernier va donc les mettre à jour...

Citation:

Envoyé par zorglubpok

Je ne suis pas très calé en IHM java, donc ma question est peut-être saugrenue, mais la solution que tu proposes fr1man me surprend ...

Et pourtant cela marche très bien !
Le plus important étant de ne pas surcharger l'EDT comme l'a indiqué fr1man, tout en modifiant le modèle dans l'EDT (qui doit contenir toutes les modifs sur l'interface).

La meilleure solution pour cela est d'utiliser SwingWorker. Exemple :

Code:

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
	// Le model et la JList :
	final DefaultListModel model = new DefaultListModel();
	JList list = new JList(model);
 
	// Le SwingWorker qui sera chargé de générer les données.
	//
	// Le paramétrage <Void, Double> signifie ceci :
	//		Void : Le type de retour de doInBackground() (inutilisé ici)
	//		Double : Le type de donnée généré qui sera passé à publish()
	//			(cela permet de traiter les objets dans l'EDT via process())
	SwingWorker<Void, Double> worker = new SwingWorker<Void, Double>() {
 
		/*
		 * doInBackground() est exécuté dans un thread séparé.
		 * Cela permet de ne pas bloquer l'interface graphique, 
		 * mais du coup on ne peut pas toucher à l'interface directement.
		 * 
		 * => On génère les données (aléatoire ici) puis on les passe à la
		 * méthode publish(). Cette dernière renverra les données vers la méthode
		 * process() ci-dessous, mais en l'exécutant dans l'EDT :
		 */
		@Override
		protected Void doInBackground() throws Exception {
 
			while (true) {
				// Attente aléatoire entre 0 et 1s :
				Thread.sleep( (int) (Math.random() * 1000) );
				// Génération d'un nombre aléatoire entre 0 et 50000:
				Double d = Math.random() * 50000;
				// Puis on publie les valeurs :
				publish( d );
			}
 
		}
 
		/*
		 * Méthode de traitement des valeurs.
		 * Cette méthode sera exécuté dans l'EDT avec 
		 * les paramètres passé à publish().
		 * Cela permet de mettre à jour l'interface (via la modèle ici)
		 */
		@Override
		protected void process(List<Double> chunks) {
			// Note : on doit parcourir tous les éléments,
			// car plusieurs appels à publish() peuvent être regroupé :
			for (Double d : chunks) {
				model.addElement(d);
			}
		}
	};
	// On n'oublie pas de démarrer le Worker :D
	worker.execute();
 
	JScrollPane scroll = new JScrollPane(list);
	scroll.setPreferredSize(new Dimension(200, 400));
 
 
	JOptionPane.showMessageDialog(null, scroll);
	System.exit(0);

a++

04/11/2009, 10h56
zorglubpok

Bon, je vais regarder ça de plus près, mais en survolant quelques pages de recherche sur Swingworker dans ce forum, j'ai vu qu'il n'était pas conseillé d'utiliser Swingworker avec un thread.
Or, j'ai absolument besoin (à moins que vous ne me trouviez une autre solution... ) d'utiliser un thread pour aller chercher périodiquement ma liste d'élèments actualisés (celle que je veux afficher) dans une base...access (donc pas de possibilité d'utiliser un trigger).
Donc, j'ai l'impression que ma seule solution est de gérer un thread pour aller chercher ma nouvelle liste et mettre à jour la JList à partir du thraed EDT.
Etes-vous en phase avec cette analyse ?
04/11/2009, 11h03
adiGuba

Heu... SwingWorker utilise déjà un thread... donc je comprend mal cette remarque ! De plus il est spécialement conçus pour faciliter l'utilisation de thread de traitement par dessus une application AWT/Swing... donc j'ai du mal à voir le problème !? (tu as testé mon code ?)

Bien sûr tu pourrais utiliser un thread "à la main", mais tu vas simplement reproduire les mêmes mécanismes que SwingWorker...

a++
04/11/2009, 11h09
zorglubpok

Citation:

Envoyé par adiGuba

Heu... (tu as testé mon code ?)

a++

Non, je suis au taf ;)
Je vais regarder ça ce soir 8-)
Merci pour vos réponses.
Je reprends contact pour vous donner mon résultat :ccool:
04/11/2009, 13h41
zorglubpok
adiGuba,

Tout d'abord merci pour l'aide que tu m'as apportée jusque là
Entre midi et 2, j'ai regardé ton code...et là, j'ai compris que j'avais accumulé du retard sur java en ne réactualisant pas mes connaissances au delà de Java SE 1.3...:calim2:
Aussi, ai-je besoin de ton aide stp.
- Pour @override, j'ai trouvé de l'info, c'est un changement par rapport à ce que je faisais avant, mais jusque là ça va.
- Pour protected void process(List<Double> chunks), j'ai été surpris - pour moi en java 1.3 on aurait écrit protected void process(List chunks) sans préciser le type des données constituants la liste....Est-on obligé en java 6 de spécifier le type (et quel est l'intérêt de le spécifier) ? Où puis-je trouver de l'info là-dessus ?
- Le summum, c'est avec SwingWorker<Void, Double> : à quoi correspondent ces déclarations <Void, Double> ?
Merci de ton aide et de tes réponses.
04/11/2009, 14h00
adiGuba
Citation:
Envoyé par zorglubpok

Pour protected void process(List<Double> chunks), j'ai été surpris - pour moi en java 1.3 on aurait écrit protected void process(List chunks) sans préciser le type des données constituants la liste....Est-on obligé en java 6 de spécifier le type (et quel est l'intérêt de le spécifier) ? Où puis-je trouver de l'info là-dessus ?
Il s'agit des Generics de Java 5.
Cela permet d'avoir un code plus sécurisé car le typeage est vérifié dès la compilation. Cela permet également d'éviter bon nombre de cast ;)
Citation:
Envoyé par zorglubpok

Le summum, c'est avec SwingWorker<Void, Double> : à quoi correspondent ces déclarations <Void, Double> ?
C'est la même chose : Les Generics permettent d'utiliser des types paramétrés avec n'importe quel type de classe, qu'il faut donc spécifier lors de l'utilisation.

Ici avec SwingWorker le premier type paramétré (Void) correspond au type de retour de la méthode doSomething(). J'ai utilisé Void car je n'ai rien à retourner... mais en cas de traitement long retournant une valeur on pourrait utiliser n'importe quel type.

Double correspond quand à lui au types des paramètres de publish()/process(), ce qui permet d'éviter plusieurs casts...

Java 1.5 a introduit plusieurs nouveaux concepts dans le langage, pour plus d'info : http://lroux.developpez.com/article/java/tiger/

a++

PS : Et inutile de m'envoyer la même chose par MP...
04/11/2009, 14h22
zorglubpok

Merci.
Si j'ai posté sur le forum...c'est que je n'étais pas certain que mon MP soit parti (je ne le voyais pas dans la liste des messages envoyés) :roll: