JTextArea refresh et autoscroll

Version imprimable

Bonjour,
je suis entrain de développer l'IHM d'un petit programme.
Dans ma fenêtre j'ai un bouton qui lance un long traitement.
J'ai donc ajouté un JtextArea à ma fenêtre pour faire une sorte de console, et y écrire l'état du traitement en cours.

Mais cette console me pose deux problèmes.

1) Afin d'écrire et de mettre à jour la zone j'ai écrit la fonction suivante :
Code:

1 2 3 4 5 6 7 private static void log(String message) { String text = MainFrame.logArea.getText(); MainFrame.logArea.setText(text + "\n" + message); MainFrame.logArea.setCaretPosition(MainFrame.logArea.getText().length() - 1); MainFrame.logArea.update(MainFrame.logArea.getGraphics()); }
Mais le update n'est pas très fluide, il fait clignoter la zone de texte.
Dois-je passer par un thread pour supprimer ces scintillements ?

2) Malgré la ligne suivante, la zone de texte ne sroll pas automatiquement, sauf à la fin du traitement :
Code:

1 2 MainFrame.logArea.setCaretPosition(MainFrame.logArea.getText().length() - 1);
j'ai essayé en déclarant mon champ ainsi, mais toujours pareil :
Code:

1 2 3 DefaultCaret caret = (DefaultCaret) logArea.getCaret(); caret.setUpdatePolicy(DefaultCaret.ALWAYS_UPDATE);
Comment faire pour afficher les dernières lignes ?

D'avance merci pour vos réponses,

Bebuck.

13/06/2016, 06h41
tchize_

Tu ne dois pas appeler update, le textarea se redessine de lui même quand son texte change.
Le scroll devrait fonctionner correctement avec ce code

Code:

MainFrame.logArea.setCaretPosition(MainFrame.logArea.getDocument().getLength());

Ta méthode log est bien appelée depuis l'EDT?

Note: pour éviter de refaire tout le textarea à chaque ligne, tu peux utiliser la méthode insertString sur son Document.

Je suis surpris que ça scrolle à la fin du traitement. Tu ne serais pas occupé de bloquer ton EDT par un traitement long ? Ce qui rendrait tout opération graphique impossible puisque le thread chargé du dessin est bloqué.

Merci de votre réponse.
Alors actuellement la fonction log n'est pas appelé depuis l'EBT, j'ai aucune gestion de thread manuelle.
Je lance l'ihm, en appuyant sur les boutons je lance une fonction qui fait le traitement assez long, et c'est depuis cette méthode que je fais mes textArea.setText("toto");

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 public static void initialization() throws IOException { log("Début de l'initialisation"); // Affichage dans ma console File tmpDirectory = new File(Utils.TEMP_PATH); if (!tmpDirectory.exists()) { tmpDirectory.mkdirs(); } log("Fin de l'initialisation"); }
J'ai essayé de changer ma fonction log comme suit :
Code:

1 2 3 4 5 6 7 8 9 private static void log(final String message) { SwingUtilities.invokeLater(new Runnable(){ public void run(){ MainFrame.logArea.append( message ); MainFrame.logArea.setCaretPosition(MainFrame.logArea.getText().length() - 1); } }); }
Mais je voulais éviter de lancer un thread à chaque fois, et sans le update la zne de texte ne se met pas à jour, et avec le update, j'ai toujours mes scintillement :?

13/06/2016, 20h34
joel.drigo

Salut,

Si ta méthode initialization() est lancée depuis un bouton, un menu ou n'importe quel autre composant d'UI AWT/Swing (via un ActionListener par exemple), alors elle s'exécutera dans l'Event Dispatch Thread, et donc l'UI ne se mettra à jour qu'à la fin de son exécution (de initialization()). Ce qui signifie que tes messages "logués" ne seront visibles qu'à la fin de l'exécution de cette méthode. Le fait de faire un SwingUtilises.invokeLater depuis cette méthode n'y changera rien.
Il faut plutôt exécuter initialization() dans un thread autre que l'EDT (par exemple, en utilisant un SwingWorker), et mettre à jour le JTextArea dans l'EDT.

Merci pour cette réponse,
je vais me faire haïr de mon ancien architecte, mais j'espérais ne pas avoir à passer par un SwingWorker.
C'est un peu lourd à mettre en place :oops:

Mais ça marche super bien.
Il n'y a pas de secret, le swingWorder ça marche.

Voila le code si ça peut aider quelqu'un.

Listener du bouton :

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
private void scanButtonActionPerformed(java.awt.event.ActionEvent evt) throws Exception {
 
        this.jFileChooser1.setVisible(true);
        int retour = jFileChooser1.showOpenDialog(null);
        if(retour == jFileChooser1.APPROVE_OPTION){
        	Utils.PATH_MOVIES = jFileChooser1.getSelectedFile().getAbsolutePath();
 
        	launchWait();
 
        	SwingWorker worker = new SwingWorker() {
 
    			@Override
    			protected Object doInBackground() throws Exception {
    				Search.listerFolder();
					return null;
    			}
    		};
        	worker.execute();
        	stopWait();
        }
 
        this.ko.setVisible(false);
        this.ok.setVisible(true);
    }

et la fonction qui écrit dans la console (le JTextArea) :

Code:

1
2
3
4
5
6
7
8
9
private static void log(final String message) {
		SwingUtilities.invokeLater(new Runnable(){
			  public void run(){
				  MainFrame.logArea.append( message );
				  MainFrame.logArea.append( "\n" );
				  MainFrame.logArea.setCaretPosition(MainFrame.logArea.getText().length() - 1);
			  }
		});
	}

Voila merci de votre aide, une fois de plus très précieuse :D

13/06/2016, 23h38
joel.drigo

Pourquoi ton ancien architecte (?) devrait-il te haîr pour utiliser un SwingWorker pour faire une tâche longue ? C'est fait pour ça, pour ne pas bloquer l'UI pendant longtemps ! Et pourquoi ça serait lourd ? Dans ton code, il n'y a qu'une ligne dans le SwingWorker, on peut difficilement faire plus simple.
Autre chose : ton SwingWorker ne produit rien...donc il pourait justement produire (en utilisant les méthodes publish() et process()) les logs (plus besoin de invokeLater pour afficher les logs). Mais, pour le coup, ça obligerait à avoir passer un callback à ta méthode de traitement (par ailleurs, ça la rendrait indépendante de l'UI de log, ce qui du point de vue architecture ne serait pas plus mal).

En revanche, c'est quoi launchWait() et stopWait() exactement ? Parce que stopWait est exécuté "immédiatement" après launchWait et tout effet conséquent sur l'UI de launchWait annulé par stopWait n'aurait pas d'effet visible. Eventuellement, pour "bloquer" l'UI pendant l'exécution de la tâche, on peut faire un "setEnabled(false)" là où tu fais launchWait(), et faire le "setEnabled(true)" dans la méthode done() sur SwingWorker, pour restaurer l'état de l'UI.
14/06/2016, 18h34
Bebuck

Il me haïrait si il lisait que j'avais pas envie d'utiliser un swingWorker :ptdr:
Après effectivement dans le cas présent la mise en place est très simple, je pensais que ça allait être un peu plus complexe.
Sinon StartWait masque des composants et affiche un gif d'attente, stopWait réaffiche les composants et masque le gif.
Mais effectivement avec le swingWorker, ça n'a plus lieu d'être
14/06/2016, 18h40
joel.drigo

Citation:

Envoyé par Bebuck

Mais effectivement avec le swingWorker, ça n'a plus lieu d'être

On peut afficher une progression pour un SwingWorker : justement, comme c'est long, c'est tout à fait justifié. Les tutoriaux classiques présentent une progression en barre, mais on peut tout à fait faire une progression de type continue avec un gif animé. En l'occurance, justement, en mettant la fin dans la méthode done() comme j'ai dit dans mon précédent post, et non à la fin de la méthode de l'écouteur, ce qui, en effet, ne sert à rien (l'évenement se termine immédiatement et non pas quand le travail du SwingWorkder se termine).
15/06/2016, 00h02
Bebuck

Tout a fait d'accord.
Je pense que je vais diviser la frame en deux. D'un côté le gif (qui disparaîtra grace au done du swingWorker) et de l'autre la console qui détaille la progression du traitement :)