Swing et thread

Faut il lancé ça GUI swing dans un thread a part ?
J'ai vu pas mal de programme qui font ça et des elements de la faq qui en parle mais d'après ce que j'avais compris le fait de rendre visible une JFrame par exemple fait lancé un thread propre a la GUI.
Personnelement, je n'ai jamais eu besoin de thread pour ça dans mes applications, et je n'ai jamais rencontré de problèmes ; mais peut etre que je n'étais pas dans les bonnes conditions. Alors threadé ou pas threadé ?

Cordialement
trax

Oui, il faut toujours créer un thread à part, ou, plus exactement, toujours se placer dans le dispatching thread, dès le départ.

Voici le modèle de la méthode main d'un programme swing, extrait d'une HelloWorld :

Code:

---

1 2 3 4 5 6 7 8

public static void main(String[] args) { //Schedule a job for the event-dispatching thread: //creating and showing this application's GUI. javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { createAndShowGUI(); } });

---

Au départ, sun disait que ce n'était pas la peine ; puis ils ont découvert un bug de conception, et, finalement, il faut toujours le faire.

il a pas été corrigé depuis parce que pas mal de code présent sur le site de sun n'implemente pas de thread pour la GUI (ancien code ou code recent) ?

Si tu sais lire l'anglais, je te conseille de télécharger le chapitre gratuit de: Desktop Java Live.

Il couvre les Threads avec Swing. Je n'y ai que jeté un oeil pour le moment mais il sembe très bien fait.

Sinon, il y a aussi un très bon article de Romain Guy sur Progx (recherche dans les archives)...

Citation:

---

Envoyé par trax44

il a pas été corrigé depuis parce que pas mal de code présent sur le site de sun n'implemente pas de thread pour la GUI (ancien code ou code recent) ?

---

Disons qu'il ne suivent pas toujours eux-meme leurs propres recommandations (comme tout un chacun).

Suivant les versions de la JVM et les OS sur lequel le programme s'execute ca peut plus ou moins causer de problemes.

Dans mon cas j'utilisais des Window avec une barre de progression et un label de message pour afficher des ecrans de demarrage et la progression du lancement des mes programmes et ben d'un coups dans Java 1.5 et sous Linux (et uniquement avec cette version sous cet OS) le programme crashait lors de son initialisation car je manipulais la Window depuis la thread du main(). J'ai donc du tout deporter dans l'EDT a grands coups de SwingUtilities.invokeAndWait() et SwingUtilities.invokeLater(). Et hop tout remarche partout pareil partout 8-) sans se vautrer !

juste une petite question aussi:

Toute les modifications d'une interface swing doit être fait avec SwingUtilities ?

par exemple un :

Code:

---

jTextField.setText("HAHAHAHAH");

---

doit être fais comme cela:

Code:

---

1 2 3 4 5 6

javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { jTextField.setText("HAHAHAHAH"); } });

---

C'est un peu lourd non ?

Tout modification de l'interface dans un thread séparé de l'EDT devrait être fait ainsi, mais il n'y a pas besoin de le faire quand on est dans l'EDT puisque invokeLater ajoute tout simplement l'événement dans l'EDT.

Oui c'est un peu lourd, mais java 6 palièra ce problème grâce à la classe SwingWorker qui utilisera notamment la nouvelle (magnifique) api java.util.concurrent.
Tu peux te procurer cette classe sur le site de Sun.
Cherche sur google tu trouveras plein d'informations là-dessus.

hmmm oui ça a l'aire plus intéressant StringWorker meme si je trouve ça tjs un peu lourd...

merci :P

Citation:

---

Envoyé par soad

hmmm oui ça a l'aire plus intéressant StringWorker meme si je trouve ça tjs un peu lourd...

merci :P

---

Juste une correction, c'est SwingWorker et pas StringWorker :lol:

EDit: Correction

Citation:

---

Envoyé par wichtounet

Juste une correction, c'est SwingWorking et pas StringWorkder :lol:

---

Juste une petite correction: c'est SwingWorker et non SwingWorking :P

Citation:

---

Envoyé par afrikha

Juste une petite correction: c'est SwingWorker et non SwingWorking :P

---

J'ai juste pu corrigé avant :P En plus j'avais 2 erreurs :oops:

Citation:

---

Envoyé par wichtounet

Juste une correction, c'est SwingWorker et pas StringWorker :lol:

EDit: Correction

---

Oui c'est juste :roll:
j'sais pas pkoi j'ai mis String... c'est ptetre pcq j'aime bien ce mot :mouarf:

Concernant l'obligation de s'activer dans le thread swing, c'est effectivement un peu lourd, mais cela n'est nécessaire que si tu réponds à un événement extérieur à l'interface utilisateur. Par exemple, au lancement, tu n'y es pas. Mais si tu réponds à un événement utilisateur (clic souris, menu, etc), tu es forcément dans le thread swing, donc pas besoin de chercher le thread swing.

Si tu es dans une situation où tu ne sais pas, tu peux utiliser javax.swing.SwingUtilities.isEventDispatchingThread().

Citation:

---

Envoyé par spekal

Oui, il faut toujours créer un thread à part, ou, plus exactement, toujours se placer dans le dispatching thread, dès le départ.

Voici le modèle de la méthode main d'un programme swing, extrait d'une HelloWorld :

Code:

---

1 2 3 4 5 6 7 8

public static void main(String[] args) { //Schedule a job for the event-dispatching thread: //creating and showing this application's GUI. javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { createAndShowGUI(); } });

---

Au départ, sun disait que ce n'était pas la peine ; puis ils ont découvert un bug de conception, et, finalement, il faut toujours le faire.

---

Wow! J'ai essayé, et ça ne marche pas top du tout!
Voici le code de ma méthode createAndShowGUI() :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public static void showGUI(){ try { MaFrame inst = new MaFrame(); inst.setVisible(true); DisplayLogo logo = new DisplayLogo(); Thread t1=new Thread(logo); t1.start(); while(t1.isAlive()){ } logo.garbageCollecting(); logo.removeAll(); logo=null;   } catch (Exception e) { e.printStackTrace(); } }

---

où MaFrame est ma classe principale qui représente la frame principale de mon appli, et DisplayLogo est une classe qui est sensée afficher un splashscreen.

Avec le coup du thread, mon splashscreen ne s'affiche pas et bloque toute l'appli. C'est grave docteur?

A quoi sert la thread sur le logo ?

Sinon j'ai peur qu'il ne te faille revoir ta fonction et insérer un ou plusieurs SwingUtilities.invokeAndWait() ou SwingUtilities.invokeLater() pour repartir ta procédure d'initialisation sur plusieurs troncons de l'EDT de manière à insérer un ou plusieurs cycle de repeinture (et de propagation d'évènements) entre les instructions et pouvoir ainsi voir s'afficher ton splash screen. Qq chose du genre (pas testé) :

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

/** Should be executed at EDT. */ public static void createAndShowGUI(){ /** @todo Verify we are at EDT and if not use SwingUtilities.invokeLater() to self-invoke. */ try { // Create and display logo. final DisplayLogo logo = new DisplayLogo(); // Initialize GUI. // Normally the logo should have had time to appear. SwingUtilities.invokeAndWait(new Runnable() { /** @inheritDoc         */ public void run() { // We may want to update a progress bar on the logo or display initialization messages. MaFrame inst = new MaFrame(logo); inst.setVisible(true); } }) logo.garbageCollecting(); logo.removeAll(); } catch (Exception e) { e.printStackTrace(); } }

---

Et dans le constructeur de ta classe MaFrame, si tu dois mettre à jour le logo alors à nouveau tu utilises SwingUtilities.invokeAndWait(). Le but du jeu n'est pas de forcement aller vite mais d'arriver à faire s'afficher les notifications sur l'écran de démarrage (rappel on insère ainsi des phases de repeinture entre des phases "actives" où le code s'exécute). Je pense que tu as plus de chance de voir les messages apparaitre avec SwingUtilities.invokeAndWait() qu'avec SwingUtilities.invokeLater() en effet on est déjà dans l'EDT (à priori) et donc il n'y aura pas de repeinture tant que l'initialisation de la frame ne sera pas terminée.

Tu peux aussi également utiliser un Timer Swing plutot qu'une Thread pour patienter qq millisecondes entre l'initialisation de ton logo et le début de la construction/affichage de la frame.

Le thread sur le logo sert à ce que le splashscreen s'affiche tout en laissant à l'utilisateur la possibilité d'atteindre et d'utiliser l'IHM principale avant la fin du splashscreen. Enfin, c'est ce que j'en ai compris (c'est pas moi qui l'ait codé)
Parce qu'en fait, le splashscreen étend JPanel, implémente l'interface Runnable et fait ça dans son run() :

Code:

---

1 2 3 4 5 6 7 8

this.setVisible(true); try { Thread.sleep(3000); } catch (InterruptedException e) { e.printStackTrace(); } this.dispose();

---

Et ça marchait très bien quand on appelait directement createAndShowGUI() dans la méthode main().

Je teste ta méthode...

C'est pas convaincant...
Sans la déclaration du thread, la méthode run() de DisplayLogo ne se lance pas, donc pas de splashscreen.

Si je le rajoute, ça bloque avec le invokeLater() alors qu'avec le invokeAndWait() ça plante carrément : j'ai pas le droit de l'appeler dans l'EDT... :(

En gros, quelle méthode utilisez-vous pour afficher un splashscreen?
Je pense que mon souci vient de là en fait...

Quel est l'objectif de ce code dans ta méthode showGUI :

Code:

---

1 2 3 4

while(t1.isAlive()) { }

---

???

A mon avis, si tu pouvais trouver mieux, ça bloquerait moins...

Citation:

---

Envoyé par spekal

Quel est l'objectif de ce code dans ta méthode showGUI :

Code:

---

1 2 3 4

while(t1.isAlive()) { }

---

???

A mon avis, si tu pouvais trouver mieux, ça bloquerait moins...

---

Ca sert à ne détruire le splashscreen qu'une fois que ses 3s de temps de vie sont achevées. (cf méthode run() que j'ai postée plus haut).

Ce n'est pas moi qui ait pondu ce code, et ça ne me paraît pas le plus propre, mais vu que ça marche, je n'y ait pas touché...

Je m'y attacherai peut-être un peu plus tard...