Discussion :

[zaboug]

Bonjour,

voilà le problème : dans mon IHM, l'utilisateur sélectionne une liste d'objets (mammos) et clique sur un bouton pour lancer l'analyse de ces objets. l'analyse étant potentiellement longue, elle est faite dans un SwingWorker. Mon but est de parcourir la liste d'objets et de lancer l'analyse sur chacun d'eux. Mais l'utilisateur doit valider l'analyse du premier avant que l'analyse du 2ème ne se lance.


j'ai fait une boucle for de ce type :

Code :

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

1
2
3
4
5
6
 
for(Object mammo : mammosSelectionnees)
{
	swingWorkerAnalyse = new SwingWorkerAnalyse(fenetre, mammo);
	swingWorkerAnalyse.execute();
}

mais les swingWorker s'exécutent tous en même temps.

Est-il possible de s'arranger pour qu'ils s'exécutent les uns à la suite des autres?

[zaboug]

Bon, finalement j'ai contourné le problème : comme l'utilisateur ne doit pas pouvoir intéragir avec l'application pendant le traitement, j'ai supprimé le swingWorker et mis le traitement long directement dans la boucle for. Comme ça j'ai bien le comportement attendu : les traitements se font bien les uns à la suite des autres et je peux attendre la validation de l'analyse précédente via une JOptionPane avant de lancer l'analyse suivante.

Dommage que je n'y ai pas pensé hier soir, ça aurait évité un post inutile dans le forum...

[Nargonath]

J'ai eu la même réflexion que toi, il y a quelques jours. Et les threads/SwingWorker & Co. sont utiles justement pour faire des tâches en parallèle. Si elles doivent être réalisées de manière séquentielle alors ils n'ont pas d'utilité ici.

Par contre, pense à donner un rendu visuel de l'avancement du chargement tels que des barres de chargements (JProgressBar) , que l'utilisateur ne pense pas que ton appli a planté alors qu'elle est justement en train de travailler

Personnellement, à titre d'exemple, j'utilise une JProgressBar indéterminé et je grise le GlassPane afin de signifier que l'interface n'est pas utilisable pour le moment.

En espérant t'avoir aidé.

[sinok]

J'ai eu la même réflexion que toi, il y a quelques jours. Et les threads/SwingWorker & Co. sont utiles justement pour faire des tâches en parallèle. Si elles doivent être réalisées de manière séquentielle alors ils n'ont pas d'utilité ici.

Pas tout à fait d'accord. En effet, pour éviter que l'application semble plantée et donc pour donner l'apparence d'une tâche longue, il est essentiel d'utiliser un Thread/SwingWorker.

En effet, effectuer ces opérations dans le thread UI principal va bloquer toutes les opérations de dessin, et de fait les progressBar & cie ne fonctionneront absolument pas (auront l'apparence d'être bloquées au démarrage et de se finir d'un coup d'un seul).

cf http://gfx.developpez.com/tutoriel/j...ing-threading/

[tchize_]

rien ne t'empeche de mettre toutes tes opération dans un seul swingworker. Tu utilise alors les JOptionPane là ou c'est nécessaire dans le traitement long

[Nargonath]

Au temps pour moi, je ne pensais pas que ça bloquerait les JProgressBar.

Mais du coup, sachant que l'utilisateur ne doit pas pouvoir interagir avec l'interface et que le traitement ne doit pas bloqué l'EDT. Il lance donc sa JProgressBar dans l'EDT puis l'action longue dans un nouveau thread. Mais la suite de l'EDT (fin de la JProgressBar) dépend d'une certaine manière des résultats du thread, donc le thread ne sert à rien puisqu'on va attendre son exécution, je me trompe ?

Ou alors, tu rentres la fin de JProgressBar dans le new thread et tu lances les instructions par le biais d'un

Code :

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

SwingUtilities.invokeLater()

?

[tchize_]

tu te trompe, ce que tu cherche à faire, c'est bloquer l'interface graphique (pas de clics), pas bloquer tous les évènements graphique!

Pour bloquer une fenetre, il suffit d'afficher une fenetre modale au dessus, les fenetre derrière ne peuvent alors plus recevoir le focus. Donc début traitement tu affiche la fenetre modale (veuillez patienter blablabla), tu lance ton gros swingworker et, à la fin du swingworker, tu fais un invokelater pour cacher la fenetre modale.

[Nargonath]

Justement j'avais déjà pensé à cette possibilité, mais j'avais rencontré des problèmes en voulant externaliser dans une autre classe le SplashScreen d'attente, pour le rendre plus générique.

Du coup j'ai opté pour utiliser une fenêtre non modale et récupérer tous les évènements souris et clavier dans le GlassPane. Tu obtiens le même résultat.