Aurelien Mazurie:
Wow ! Ca marche maintenant =)
Par contre je n'arrive pas � comprendre pourquoi, ni o� �tait l'erreur.
Ce que j'ai maintenant, c'est un thread appell� apr�s la cr�ation des objets Swing, qui contient des instructions pour injecter des donn�es dans ces objets, + une instruction invokeLater() qui appelle... un autre thread (un Runnable) qui injecte les donn�es les plus grosses (celles destin�es au JTable). Bizarre ?
Ok.

Certes mais il n'est jamais demarre ;-(

Pourquoi n'est-il jamais d�marr� ?
Parce que sa methode start() n'etait pas appele.
Pourtant il l'est bien � un moment ou � un autre puisque les donn�es finissent par �tre charg�es, et sont affich�es dans les composants Swing.
Non, tu executes sa methode run() mais celle-ci s'execute dans le thread courant (a savoir AwtEventDispatchThread).

En fait il faut faire:
  new ManageObj(dataObj).start();

Ok, ca c'est donc fait juste apr�s avoir cr�� les composants Swing.
Disons au moment ou tu veux commencer a recuperer les donnees. Ca peut aussi etre apres display().

et dans la m�thode run():
  for each data
    SwingUtilities.invokeLater(new Runnable()
    {
      public void run() { add_to_frame(data); }
    });

Et donc l�, � l'int�rieur du Thread, j'impl�mente un Runnable ?? Pour chacune des donn�es � injecter en plus ?
Oui. Ou bien tu reutilises le meme en le parametrant.

Que ce passe-t'il pour les instructions contenues dans le Thread (et non pas dans le Runnable qui y est inclu), et qui elles aussi injectent dans les composants Swing (de toutes petites quantit�s de donn�es, cependant) ?
Elles ne devraient pas toucher aux composants Swing (car elles ne sont pas dans le bon thread). Deplace les dans un Runnable pour eviter tout risque de deadlock.

En r�sum�, le Thread est-il r�ellement utile ?
Oui
Ne peut-on pas appeller, juste apr�s avoir cr�� les composants Swing, directement des Runnable gr�ce � invokeLater() ?
Si, a condition que ce soit rapide. Mais en general, il faut mieux faire un thread separe (et en plus avec une priorite inferieure).

Ou le Thread qui les enveloppe a-t'il une fonction au niveau de la event queue qui assure que ces Runnable seront bien execut�s ?
Non. Le thread s'execute independament de la EQ mais y ajoute simplement des ActiveEvents(Runnable).

Normal  puisque tu bloques le thread (avec la tache ManageObj).

? Je ne comprends pas. Pourquoi mon thread initial (c'est � dire, justement ManageObj()) est-il bloqu� ?
Je me suis mal exprime. Je voulais dire que le AwtEventDispatchThread est en train d'executer la methode run() de ManageObj (alors que cette methode devrait etre execute par ManageObj lui meme).

Remarque, il semble bien
que je n'ai pas la main � ce moment... Mmm...
Si tu n'as pas la main, c'est que tu es dans le AwtEventDispatchThread et que tu as donc le meme probleme (simplement il doit y avoir un composant qui demande un repaint immediat qq part).

Guillaume

Répondre à