Ajouter une pause entre deux instructions

Version imprimable

28/03/2017, 18h39
tarpal

Ajouter une pause entre deux instructions

Bonjour
Dans un programme java je souhaite rajouter une pause de 5 secondes entre deux instructions.
cela me permettra de debugger mon code.
J'ai mis le code :

Code:

Thread.Sleep(5000);

Mais j'ai l'erreur suivante :
Surrond with Try/Catch mais je ne comprends pas.
Quelqu'un peut-il me corriger ?
Sinon comment faire en java avec ECLIPSE pour aller pas à pas ?
Merci pour vos réponses
A+
28/03/2017, 19h07
joel.drigo

1 pièce(s) jointe(s)
Salut,

Normalement, le mieux pour déboguer, c'est d'utiliser le mode debug.

L'instruction Thread.sleep() permet en effet de mettre en pause un thread. Comme cette pause peut être interrompue, elle soulève une exception de type InterruptedException. En théorie, il faut traiter cette exception en fonction de ce qu'on veut faire si la pause est interrompue. Comme c'est juste pour un test, tu peux te contenter de simplement l'ignorer.

Attention, toutefois, à l'utilisation de ce genre de trucs dans le thread graphique : mettre en pause le thread graphique signifie bloquer l'interface pendant cette pause (l'affichage comme la réactivité).

Donc, pour ta seconde question, le mode pas à pas comme tu dis, c'est encore le mieux. Dans Eclipse, tu peux voir juste à gauche du bouton de lancement de programme, un bouton avec un insecte vert (la flêche rouge sur l'image): c'est le lancement du mode debug. C'est juste une alternative du lancement d'exécution normale : ça utilise la même configuration. Si tu n'as jamais lancé le programme, il faudra utiliser le menu contextuel sur le source de la classe qui contient la méthode main, et utiliser le menu "Debug as".

Il est nécesssaire par ailleurs d'indiquer à quel moment du veux commencer l'exécution pas. Si on commençait dès le début, tu passerais un temps fastidieux à avancer dans le code jusqu'à l'endroit qui t'intéresse, éventuellement même à passer dans les méandres du code interne des classes Java que tu utilises. Il faut donc placer un breakpoint :
- soit double-cliquer dans la zone située juste à gauche de la réglette avec le numéro de lignes (qui n'est pas affichée par défaut sur toutes les version d'Eclipse : voir la préférence "Show line numbers").
- soit cliquer avec le bouton droit dans la même zone pour afficher menu contextuel et faire apparaitre les différentes options qui te permettront de contrler les breakpoints.^
- Enfin, lorsque le mode debug démarre, Eclipse va te proposer de passer dans une perspective spéciale avec des fenêtres dédiées (où tu pourras consulter l'état de tes variables par exemple). Tu verras également une barre d'outils dédier à l'exécution pas à pas, avec des boutons qui ressemblent aux boutons d'un magnétoscopes (pause, stop, avancer) et des boutons juste à droite (des fêches coudées ou courbées) pour avancer pas à pas (descendre dans une méthode, sauter une méthode, remonter à la méthode appelante)
Dans l'image, j'ai entouré en bleu l'icône qui indique le breakpoint ajouté, dans la zone où il faut double-cliquer et j'ai entouré en jaune les boutons pour contrôler l'exécution.

Pièce jointe 258655
29/03/2017, 10h56
tarpal

Merci @joel.drigo @ pour tes explications...
C'est très clair et ça me fait progresser dans ma connaissance de Eclipse.
Par contre pour faire mon pas à pas dans le mode Debug je n'ai pas bien compris.:calim2:
J'ai 4 fichiers :
Main
Fenetre
PanneauUn
PanneauDeux
Tu me dis de lancer le debug dans le Main
Hors c'est dans ma Class "PanneuUn" que je faire un pas à pas.
Puis-je avoir plus de précision ?
Merci de ton suivi
A+

Tu as beau avoir plusieurs classes, tu lances ton programme forcément en appelant une méthode "main" (avec la signature public static void main(String[] args) (excepté s'il s'agit d'une applet, ou d'une application web, ou toute autre type de code exécuté dans un container, mais c'est une autre histoire, et ça ne change rien en fait, à part la façon de lancer l'exécution).
L'exécution d'un code Java en gros, c'est l'exécution dans un thread (processus) d'une séquence d'instructions, qui commence donc pour le thread principale par l'exécution de cette méthode main.
Le fait que tu aies besoin de déboguer un code dans une autre classe impose juste que tu mettes ton breakpoint juste dans ce code, mais que tu lances ton application exactement de la même manière que si tu le lancais en mode normal (pas debug), qu'il fasse au moins la même chose.
Mettons que je veuille déboguer ceci :
Code:

1 2 3 4 5 6 7 public class Testeur { public static void main(String[] args) { final int a=5; System.out.println(MathUtils.calculFactorielle(a)); System.out.println(MathUtils.calculFactorielleRecursivement(a)); } }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public class MathUtils { public static int calculFactorielle(int n) { if ( n<0 ) throw new IllegalArgumentException(); int r=1; for(int i=1; i<=n; i++) { r *= n; } return r; } public static int calculFactorielleRecursivement(int n) { if ( n<0 ) throw new IllegalArgumentException(); if ( n==0 || n==1 ) return 1; return n*calculFactorielleRecursivement(n-1); } }
Parce que ça m'affiche :

Citation:

3125
120

donc qu'il y'a manifestement un problème quelque part (et oui, en plus de constater que les deux résultats qui devraient être égaux alors qu'ils ne le sont pas, j'ai triché et utilisé une calculatrice pour savoir combien donnait 5! ;)).
Pour tester, je lance Testeur.main() en exécution normale, et pour déboguer je lance toujours Testeur.main() en debug. Et je vais mettre un breakpoint sur la ligne int r=1 pour suivre l'évolution de mon calcul faux (mais sans avoir à avancer sur le main(), le System.out.println, l'appel de calculFactorielle, tous ça je m'en moque. A la limite, si c'était la mauvaise méthode qui était appelée, mon programme irait jusqu'au bout sans passer par le breakpoint et j'aurais l'information nécessaire pour corriger le problème. A partir de int r=1, je vais donc exécute pas à pas le code :

breakpoint: r=1
step over: r=1, i=1
step over: r=5, i=1
step over: r=5, i=2
step over: r=25, i=2
...

(bon, en théorie, au 3, je devrais déjà m'arrêter, parce que r est déjà faux ;))

29/03/2017, 18h06
tarpal

Re,
J'ai bien réussi à configurer mes Breakpoint : j'ai bien un symbole devant le numéro de ma ligne.
Par ailleurs si je clik droit sur le numéro de ligne j'ai bien une fenêtre qui s'ouvre où je peux sélectionner "Disable Breakpoint" ou bien "Enable Breakpoinr"
Jusque là ça va
Mais tu dis :

Citation:

Enfin, lorsque le mode debug démarre, Eclipse va te proposer de passer dans une perspective spéciale avec des fenêtres dédiées (où tu pourras consulter l'état de tes variables par exemple). Tu verras également une barre d'outils dédier à l'exécution pas à pas, avec des boutons qui ressemblent aux boutons d'un magnétoscopes (pause, stop, avancer)

Hors si je lance le programme en mode debug ( ou en mode normal) je n'ai pas la perspective que tu m'annonces.
Le programme se lance sans breakpoint
Je ne comprends pas ce qui se passe
A+
29/03/2017, 18h08
joel.drigo

C'est que ça ne passe pas par le breakpoint à priori. Tu as beaucoup de classes ? Tu peux peut-être nous montrer le code ?

OK
J'ai 4 fichiers : MainTest - FenetreTest - PanneauTestUn - PanneauTestDeux
Voici mes codes :
MainTest :

Code:

1
2
3
4
5
6
7
8
9
package testGraphics;
 
public class MainTest {
 
	public static void main(String[] args) {
		FenetreTest frame = new FenetreTest();
        frame.getContentPane();
	}
}

FenetreTest :

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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
package testGraphics;
 
import java.awt.Color;
import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JLabel;
import javax.swing.ImageIcon;
import javax.swing.JButton;
 
// Code Pour la Fenêtre
public class FenetreTest extends JFrame
{
	private static final long serialVersionUID = 1L;
 
	public FenetreTest()
      {  
       int x = 1000;
       int y = 600;
 
        this.setTitle ("PROGRAMME TEST GRAPHICS");
        this.setSize(x, y);
        this.setLocation(350,100);
        this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 
        // Création du conteneur
        JPanel pan = new JPanel();
        pan.setBackground(Color.ORANGE);
      //On prévient notre JFrame que notre JPanel sera son content pane
        this.setContentPane(pan);
 
        // Création des boutons et implémentation dans le conteneur JPanel
 
        JButton but1 = new JButton ("CLIQUEZ ICI pour Charger Image",new ImageIcon("C:/Users/François/Documents/Dossier JAVA/Appareil-Photo.jpg"));
        but1.setBackground((Color.CYAN));   
        but1.addActionListener(new Traitementbut1());
 
        JButton but2 = new JButton ("CLIQUEZ ICI pour Réaliser Mesures ",new ImageIcon("C:/Users/François/Documents/Dossier JAVA/Metre-Mesure.png"));
        but2.setBackground((Color.GREEN));
        but2.addActionListener(new Traitementbut2());
         // On crée un JLabel pour dialoger avec l'utilisateur
        JLabel lab = new JLabel (" MON  IMAGE  SERA  TELECHARGEE  ICI ");
 
      //On définit le layout à utiliser sur le ContentPane
        this.setLayout(new BorderLayout());
        //On ajoute les boutons et image dans le Layout
        this.getContentPane().add(but1,BorderLayout.NORTH);
        this.getContentPane().add(but2,BorderLayout.SOUTH);
        this.getContentPane().add(lab,BorderLayout.CENTER);
 
        this.setVisible(true);
         }
	public class Traitementbut1 implements ActionListener
	{
		public void actionPerformed(ActionEvent e)
		{	
			FenetreTest.this.getContentPane().add(new PanneauTestUn());
			FenetreTest.this.revalidate();
		System.out.println(" J'ai cliqué sur boutton Charger Image  !");
	    }
	}
    public class Traitementbut2 implements ActionListener
         {
            public void actionPerformed(ActionEvent e)
            {
            	FenetreTest.this.getContentPane().add(new PanneauTestDeux());
    			FenetreTest.this.revalidate();	
            System.out.println("J'ai cliqué sur boutton Réaliser Mesures !");
            }
         }
}

PanneauTestUn :

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
package testGraphics;
 
import java.awt.Graphics;
import java.io.IOException;
import java.awt.Image;
import javax.imageio.ImageIO;
import javax.swing.JPanel;
import java.io.File;
 
public class PanneauTestUn extends JPanel
{
	private static final long serialVersionUID =1L;
 
	public void paintComponent(Graphics g){
 
		// dessine une image 
		try {
			Image img = ImageIO.read(new File("C:/Users/François/Documents/Dossier JAVA/Dessin.jpg"));
 
		//pour une image de fond 
		 g.drawImage(img, 0, 0, this.getWidth(), this.getHeight(), this); 
		    }
		catch (IOException e) 
		    { e.printStackTrace();
	        }
 
		//Pour écrire sur la console
	    System.out.println(" J'ai bien chargé mon Image!"); 
 
	  } 
}

PanneauTestDeux :

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
package testGraphics;
 
import java.awt.Graphics;
import java.io.IOException;
import java.awt.Image;
import javax.imageio.ImageIO;
import javax.swing.JPanel;
import java.io.File;
 
public class PanneauTestDeux extends JPanel
{
	private static final long serialVersionUID =1L;
 
	public void paintComponent(Graphics g){	
		// dessine une image 
		try {
			Image img = ImageIO.read(new File("C:/Users/François/Documents/Dossier JAVA/Dessin2.jpg"));
 
		//pour une image de fond 
		 g.drawImage(img, 0, 0, this.getWidth(), this.getHeight(), this); 
		    }
		catch (IOException e) 
		    { e.printStackTrace();
	        }
		//Pour écrire sur la console
	    System.out.println(" J'ai bien chargé mon Image!"); 
 
	  } 
}

J'espère que ce sera clair.

29/03/2017, 18h35
joel.drigo

Et le breakpoint, tu le mets où ?
29/03/2017, 18h52
tarpal

Je souhaitais le mettre à la ligne 44 de FenetreTest
code :

Code:

JLabel lab = new JLabel (" MON IMAGE SERA TELECHARGEE ICI ");

En effet je voulais vérifier si je pouvais mettre successivement 3 JLabel différents à 2 secondes d'intervalle
Afin que mon JLabel soit " animé" :oops:
Ce n'est peut-être pas la bonne méthode mais c'est en programmant que j'apprends à programmer...:calim2:
Je rappelle que je débute en java.
Merci pour ton suivi
A+

Pour le problème de debug, je n'ai pas de souci personnellement. Si je mets un breakpoint à la ligne que tu dis, mon programme s'arrête bien là en mode debug et Eclipse bascule sur la perspective de debug.

Sinon, on effet, ce n'est pas du tout la bonne manière de procéder pour faire clignoter un label, ou tout autre forme d'animation (faire défiler le texte, changer le texte, etc...).

L'affichage ainsi que l'intéraction de Swing (c'est une manière assez commune de procéder, pas spécifique à Swing) se fait dans un processus spécifique parallèle au processus standard, celui dans lequel s'exécute la méthode main. Le processus en question s'appelle l'Event Dispatch Thread (ou EDT). Il dort la plupart du temps. Lorsque c'est nécessaire, ou lorsqu'on le demande, le thread est réveillé et procède au traitement d'une file évenementielle : un truc dans lequel il y a des trucs à faire depuis la dernière fois où il était réveillé. En gros, il se met à rafraichir l'UI, donc à exécuter les méthodes paintComponent() que tu as écrites dans PanneauTestUn et PanneauTestDeux entre autres, et traite le dispatch des évenements qui va éventuellement exécuter le code des écouteurs d'évenements (par exemple le code de la méthode actionPerformed de Traitementbut1 que tu as écrite).

Même quand tu n'écris pas toi-même du code dans paintComponent, il y a quand même du code de cette méthode dans les classes Swing. Du code qui va peindre le fond du composant, pour les JLabel du code qui va dessiner le texte du label, pour les JButtons en plus du code qui va faire le rendu du bouton (l'effet de 3D, le fait que le bouton s'enfonce quand on clique dessus, etc.). Tout l'affichage donc est fait comme ça. Si tu mets une pause dans ce process, tu gèles l'affichage, mais aussi les évenements. Le temps de la pause, l'UI de application ne répond plus.

2 autres choses à ce sujet :

tout ce qui nécessite un rafraichissement de l'ui va donc déclencher le réveil de l'EDT et redessiner les composants que Swing estime devoir redessiner ou ceux qu'on a demandé à redessiner (par l'appel de repaint). Par exemple, lorsqu'on agrandit la fenêtre, il y a du code qui logiquement redessine la fenêtre, puisqu'il y a une partie qui n'était pas affichée avant qui va devoir l'être maintenant. Donc la méthode paintComponent est susceptible d'être appelée plusieurs fois, au besoin. Comme dans ton code tu charges un fichier, ce fichier est susceptible d'être chargé plusieurs fois. Ce qui est assez lourd pour le système (les IO c'est relativement lent), et peut bloquer d'autres applications ou être bloqué par d'autres applications (le nombre de têtes d'un disque est limité physiquement). En plus, il faut tenir compte de la décompression, de la taille du fichier, du temps qu'il faut pour allouer la mémoire pour charger le fichier, etc.) Alors même s'il y a des caches système, ou que le disque soit du SSD, ou autre raison, il ne faut pas hésiter à perdre un peu de mémoire pour charger le fichier au moment où on le connait et le garder en mémoire, et afficher l'image en mémoire. En d'autres termes éviter les IO ou autres traitement relativement lents dans les méthodes exécutées dans l'EDT
Il y a également une optimisation faite par Swing : le contexte graphique (la zone de mémoire qui sert de buffer pour dessiner sur l'écran, plus toute la mécanique qu'il y a pour la gérer et desiner dedans facilement sans se peler des manipulation d'octets), ce qu'on manipule par l'entremise de l'instance de classe Graphics, est recyclée. La même va être utilisée par plusieurs composants pour faire leur rendu. L'EDT dessine donc un composant dans la mémoire du Graphics l'envoie en quelque sorte sur l'écran, puis passe à un autre composant : pour éviter de perdre du temps, il laisse ce qu'il y avait de dessiné pour le composant précédent. Le code des composants Swing s'occupe de dessiner un fond pour effacer les trucs qui sont encore là. Mais quand tu redéfinis une méthode de Swing, sans appeler la super méthode, tu supprimes de fait l'exécution de ce code. Tant que tu dessines bien sur l'ensemble de la surface visible du composant, ce n'est pas grave puisque tu recouvres tout ce qui est visible, mais sinon tu risques de voir des bouts d'un autre composant dans ton composant. C'est pourquoi il faut prendre l'habitude d'appeler le super quand on redéfinit paint ou paintComponent, c'est toujours utile (surtout qu'il peut y avoir éventuellement d'autres choses que sont censées être faites et que tu ne connais pas forcément (pas forcément du dessin, mais du paramétrage, comme du clipping ou l'antialiasing par exemple).

Une troisième point annexe concerne ce que tu fais dans ton code avec le BorderLayout. Un conteneur de composants est censé pouvoir afficher plein de composants, 1, 10, des centaines. Le BorderLayout lui n'en gère que 5. Dont un seul au centre. Quand tu ajoutes un composant dans un conteneur qui a le layout manager BorderLayout, avec la contrainte par défaut, il est ajouté au centre. Mais le composant précédent lui est toujours là dans le conteneur avec une position et une dimension déterminées lors du précédent layout. Mais le Border Layout lui ne le connait plus, donc n'aura plus d'agissement dessus. Selon les manipulations de l'UI on peut donc se retrouver avec des bouts de vieux composants qui trainent, sans compter que tous ces composants consomment mémoire et CPU lorsqu'il faut les parcourir pour les traiter. Il vaut mieux donc supprimer un composant quand on le remplace : le Layout Manager ne fait pas ça tout seul malheureusement.
Dans ton cas, tu pourrais par exemple stocker le dernier composant ajouté au centre dans un attribut de la classe de fenêtre et dans les ActionListener le retirer du content pane s'il n'est pas null.
On peut le faire sans ça, avec cette méthode, qu'il suffit donc d'appeler (avant) à chaque fois que tu fais FenetreTest.this.getContentPane().add(new PanneauTestUn()); ou FenetreTest.this.getContentPane().add(new PanneauTestDeux()):
Code:

1 2 3 4 5 6 private void removeCenterComponent() { Component component = ((BorderLayout)getContentPane().getLayout()).getLayoutComponent(BorderLayout.CENTER); if ( component!=null ) { getContentPane().remove(component); } }
Revenons à nos moutons : afficher un texte qui clignote. Pour faire ça, il faut qu'on réveille à intervalle régulier l'EDT pour qu'il rafraichisse l'affichage. Il y a un moyen simple de base (dans des cas plus complexe, il faudra éventuellement faire plus complexe) : la classe javax.swing.Timer permet de déclencher un ActionListener tout les n millisecondes. Imagine faire le traitement que tu veux faire (par exemple faire clignoter un texte du rouge au noir), et que tu le fasses par un JButton ou tu cliquerais par exemple toutes les 2 secondes par exemple. Et bien le code est exactement le même pour l'action listener de ton bouton et celui qui va être utilisé par le timer. En gros, si tu es capable d'animer un truc en cilquant régulièrement sur un bouton, il suffit d'utiliser l'actionlistener de ce bouton avec un timer, et l'animation sera automatique.
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 JLabel label= new ... ActionListener clignoter = new ActionListener() { private boolean on; public void actionPerformed(ActionEvent event) { on=!on; // on inverse l'état de on if ( on ) { label.setForeground(Color.RED); } else { label.setForeground(Color.BLACK); } } }; Timer timer = new Timer(2000, clignoter); // exécuter l'action toutes les 2 secondes timer.start(); // lancer le timer
Attention à bien importer javax.swing.Timer (il y en a d'autres).

30/03/2017, 11h33
tarpal

Merci @ joel.drigo @ pour la clarté et la qualité de ta réponse.
Comme tu as pu le constater je ne maîtrise pas encore Java.
Quand je manipais sur C++ avec Code:Block je prenais quelques précautions élémentaires
comme le fait de manipuler très précautionneusement les pointeurs...
Et faire attention aux fuites de mémoire...
Mais là je découvre vraiment Java.
J'aurais dû m'en douter qu'un ByteCode (java) ne pouvait pas se comporter comme une code en C++ qui est plus proche du langage machine.
Je vais donc essayer de trouver les bons cours et tutoriels pour continuer à avancer ( quelques conseils seraient les bien venus.)
Mille mercis pour la leçon
Je pense mettre le sujet comme résolu même si ce n'est pas tout à fait le cas
Je lèverais c'est sûr d'autres sujets
A+