Inter-relation entre Jslider, Jbutton et JTextField

Version imprimable

05/12/2016, 03h44
benoit256255

Inter-relation entre Jslider, Jbutton et JTextField

Bonjour ,

Mon cours Java 2 commence à nous faire voir le merveilleux monde de l'interface graphique...

Pour mon dernier travail de session, je dois faire un programme avec interface....

J'ai certaine difficulté à trouver le «comment» pour faire un lien entre slider et un textfield

Ce que je veux dire par là ..! Lorsque je bouge la bar du slider ou que je change la valeur numérique du textfield, l'un et l'autre doit se changer

Slider passe de 30 à 50, le textfield doit se changer pour 50 automatiquement

Ces opérations auront pour but de faire une animation plutard d'un fichier obj

Merci

Salut,

Il suffit d'écouter les changements du slider et d'affecter la valeur actuelle au champ. Il serait judicieux d'utiliser un JLabel plutôt qu'un JTextField, parce qu'un JTextField sert à faire la saisie, donc il faudrait synchroniser dans l'autre sens, et c'est un peu plus compliqué, surtout qu'un JTextField permet de saisir des lettres. En plus, il faudra faire attention aux boucles évenementielles (le slider qui met à jour le field qui met à jour le slider qui met à jour le field, etc, infiniment).

Avec un JLabel :
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 public class DemoJSlider { public static void main(String[] args) { JFrame frame=new JFrame("Démo"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); JPanel sliderPanel=new JPanel(); JSlider slider = new JSlider(1,100,50); sliderPanel.add(slider); JLabel field = new JLabel(); field.setAlignmentX(JLabel.RIGHT); field.setText("50"); sliderPanel.add(field); slider.addChangeListener(e-> field.setText(String.valueOf(slider.getValue()))); // on affiche la valeur du slider dans le label frame.add(sliderPanel); frame.setSize(300,64); frame.setLocationRelativeTo(null); frame.setVisible(true); } }
Pour un JTextField, ou un JTextFormattedField, on peut écouter les changements par addActionListener(), mais ça ne prendra en compte que les changements après validation de la saisie (par entrée ou sortie du champ). Pour appliquer le changement sur le slider au fur et à mesure de la saisie, on peut écouter les changements sur le document (field.getDocument().addDocumentListener(...), mais c'est encore plus compliqué, parce que la valeur n'est pas encore entièrement validée dans le composant.

Merci Joel

Toujours un plaisir de lire tes réponses si claires et très utile à mes yeux de programmeur en herbe :)

Je dois utiliser un JTextField pour mon tp...

Voici mon code et qui semble être fonctionnel même avec des validations :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
JSlider barreProgression = new JSlider(-180, 180, 0);
JTextField angle = new JTextField(String.valueOf(barreProgression.getValue()));
 
 
angle.addKeyListener(new KeyAdapter()
            {
                @Override
                public void keyReleased(KeyEvent ke) {
                    String typed = angle.getText();
 
                    if (typed.length() <= 4){
                        if (typed.charAt(0) == '-' && typed.substring(1, 3).matches("\\d+") || (typed.matches("\\d+"))){
                            int value = Integer.parseInt(typed);
                            barreProgression.setValue(value);
                        }
                    } else {
                        angle.setText(String.valueOf(barreProgression.getValue()));
                        return;
                    } 
                }
            }
        );

Je me souviens plus, comment le faire, si je dois spécifier si c'est du code JAVA que j'inscris dans mes messages...

Merci

Citation:

Envoyé par benoit256255

Voici mon code et qui semble être fonctionnel même avec des validations :

Finalement pas tout à fait fonctionnel

Voici ma logique :

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
 
Si la longueur des caractères est inférieur ou égal à 4 {
   Si le premier charactere est '-' { //On peut dire à partir de là que nous avons potentiellement un nombre négatif
        Si la chaîne de charactere entre 1 et 3 est numérique {
                   on transforme le texte en une valeur entière
                            Si valeur est plus petite que -180 {
                                 JSlider garde une valeur de -180
                            } Sinon {
                                   Il prend la valeur sélectionner 
                                   On ajuste le JSlider en conséquence
                            }         
        } Sinon {
              JTextField reprend la valeur du JSlider non modifier
              //Un retour peut-être ici ?
       }
 
  } Sinon Si la chaîne de charactere est numérique { // parce que ici on parle de nombre positif automatiquement
                    on transforme le texte en une valeur entière
                    Si valeur est plus grande que 180 {
                           JSlider garde une valeur de 180
                      } Sinon {
                                Il prend la valeur sélectionner 
                                On ajuste le JSlider en conséquence
                          }   
} Sinon {
       JTextField reprend la valeur qui était dans le JSlider
       // return;
}

Voilà mon pseudo code

Je l'ai transformer partiellement en code mais vraiment pas sur et ca ne marche pas dans toutes les situations...

Mon problème est que mon prof veut toujours avoir un return par méthode....

Des idées ?!

Ton test Si la longueur des caractères est inférieur ou égal à 4 { devrait être si la longueur est supérieur à 0 et inférieur ou égal à 4, sinon tu auras des StringIndexOutOfBoundException (quand la chaîne saisie sera vide)
Au lieu de if (typed.charAt(0) == '-' && typed.substring(1, 3).matches("\\d+") || (typed.matches("\\d+"))){ tu peux écrire plus simplement :
type.matches("-?\\d+"));ça t'évitera en plus d'avoir des StringIndexOutOfBoundException sur le substring (si type.length()==2 par exemple !)

Citation:

Envoyé par benoit256255

Mon problème est que mon prof veut toujours avoir un return par méthode....

Des idées ?!

(C'est complètement c**:roll:) Mais tu peux foutre un return inutile systématiquement à la fin de tes méthodes void. Il suffit qu'il n'y ait pas de code exécutable après.

ça donnerait un truc comme ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 field.addKeyListener(new KeyAdapter() { public void keyReleased(java.awt.event.KeyEvent e) { String typed = field.getText(); if (typed.length()>0 && typed.length() <= 4){ if (typed.matches("-?\\d+")) { int value = Integer.parseInt(typed); if ( value>=slider.getMinimum() && value<=slider.getMaximum()) { slider.setValue(value); } else { field.setText(String.valueOf(slider.getValue())); } } } else { field.setText(String.valueOf(slider.getValue())); } return; } });
Mais ça pose un petit problème de confort à la saisie : si tu veux vider le champ, pour saisir une nouvelle valeur, la valeur du slider sera remise systématiquement... très agaçant. De plus, on ne gère pas le cas du - tout seul qui peut rester quand on sort du champ (pour aller vers un autre champ). De la même façon si tu saisis aaa dans le champ (n'oublie pas également qu'on peut faire de la saisie par copier/coller), et que tu sors, cette saisie reste ! On pourrait

soit intervenir sur le focusLost (FocusChangeListener)
soit utiliser un InputVerifier pour empêcher de sortir du champ tant que la saisie n'est pas ok. Mais ça peut être frustrant de ne pas pouvoir sortir du champ et annuler la saisie.
pour éviter le problème du champ vide, il faudrait ne pas remplacer la saisie par la valeur du sldier lorsqu'elle est vide (le faire seulement quand on sort du champ)

Pouir éviter de pouvoir saisir autre chose que des chiffres et -, voire éviter de saisir un nombre en dehors des limites, tu peux intervenir sur le KeyEventListener en ajoutant :
Code:

1 2 3 4 5 public void keyTyped(java.awt.event.KeyEvent e) { if ( e.getKeyChar() != KeyEvent.VK_BACK_SPACE && "-0123456789".indexOf(e.getKeyChar())==-1 ) { e.consume(); } }
Ici on bloque tout ce qui n'est ni backspace ni un chiffre ou -. Tu peux l'adapter par exemple pour qu'on ne puisse pas saisir de - si la longueur de la chaîne est supérieur à 0, on ne pas saisir de nouveau chiffre si on sort des limites du slider. Attention à prendre en compte la sélection dans le champ (sinon on ne peut plus remplacer).
Ceci ne bloque pas la saisie par copier/coller : il faut traiter spécifiquement ce cas, pour interdire de coller des lettres... c'est le souci quand on utiliser des évenements de bas niveau : il faut prendre en compte tous les cas...
A noter qu'on peut également utilser un DocumentFilter pour gérer la saisie, mais je crains que cela ne soit pas évident de le faire cohabiter avec ton keyReleased. Il faudrait tester pour voir les conflits possibles.

Citation:

Envoyé par benoit256255

Je me souviens plus, comment le faire, si je dois spécifier si c'est du code JAVA que j'inscris dans mes messages...

Dans le forum Java, ce n'est pas nécessaire, c'est automatique. Sinon, il suffit d'écrie [code=java]...[/code]

07/12/2016, 19h15
benoit256255

Merci Joel,

Toujours utile tes réponses !

Hier soir , durant mon cours, j'ai discuté avec deux de mes collègues du tp et eux autres utilise des try/catch et j'ai pensé à NumberFormatException vont tout ce qui n'est pas un nombre ne sera pas retenu...

Bonne idée et surement plus simple que le chemin j'avais entamé lol

J'ai laissé de côté les validations et je me concentres à faire fonctionner mon tp...

Si tu es curieux de voir à quel point notre prof est un peu zélé dans son dernier tp que je trouve quand même le fun mais très complexe pour moi de comprendre...

http://www.labunix.uqam.ca/~malenfan...tp3aut2016.pdf

Je progresse lentement mais je progresse...

Bon après-midi

mmm je remarque que dans le sujet il est dit "Un seul return par méthode" ce qui est strictement différent de "mon prof veut toujours avoir un return par méthode....".
Dans le second cas on impose d'avoir toujours le mot return dans toute méthode.
Dans le premier cas, on impose d'avoir au maximum un return par méthode... qui est une règle de base de la programmation structurée (un seul point d'entrée, un seul point de sortie).
C'est simplement que tu ne peux pas écrire par exemple :
Code:

1 2 3 4 5 6 7 8 public int chercher(String[] array, String value) { for(int i=0; i<array.length; i++) { if ( array[i].equals(value) ) { return i; } } return -1; }
Mais plutôt :
Code:

1 2 3 4 5 6 7 8 9 public int chercher(String[] array, String value) { int position=-1; for(int i=0; i<array.length && position==-1; i++) { if ( array[i].equals(value) ) { position = i; } } return position; }
Un seul return, pas de break...

[mode débat on]C'est un sujet qui fait débat. Bien qu'étant particulièrement partisant de la programmation structurée, et en particulier de ce point (un seul point de sortie), j'admets qu'il existe parfois des cas où c'est quand même plus pratique et concis de faire plusieurs points de sortie, et qu'il vaut mieux le faire. Et d'ailleurs je le pratique moi-même. Mais dans le cadre d'un apprentissage, il vaut mieux respecter cette règle, strictement, dans tous les cas, jusqu'à ce que ça devienne un réflexe. Ensuite, quand tu auras une plus grande maitrise de la programmation, tu pourras décider quand tu peux te permettre de déroger à cette règle.
C'est comme le mot clef static : j'ai l'habitude de dire aux débutants : jamais utiliser le mot clef static, excepté pour les "constantes", du type "static final", ou pour les méthodes utilitaires (et encore, c'est juste pour simplifier au détriment de la flexibilité). Ainsi, le reflexe à avoir, c'est quand on est obligé de mettre static dans un autre cas, c'est qu'on a fait une erreur quelque part. Ensuite, lorsqu'on maîtrise plus la programmation, on pourra utiliser static lorsque c'est indispensable.
[mode débat off]

Citation:

Envoyé par benoit256255

eux autres utilise des try/catch et j'ai pensé à NumberFormatException vont tout ce qui n'est pas un nombre ne sera pas retenu...

Il faut toujours éviter de faire exécuter un code dont on sait qu'il va provoquer une exception qu'on va attraper volontairement : cela prend des ressources inutilement (du temps, de la mémoire). On peut déroger à cette règle lorsque le code de test est vraiment beaucoup plus complexe que de simplement laisser faire, ou que tester avant de faire ne fera pas spécialement gagner du temps, ou tout autre cas où on peut pas faire autrement (par exemple, on ne va pas tester la conformité d'un fichier xml avant de le lire (ça reviendrait à le lire 2 fois) : autant le lire et s'il est incorrect on aura une exception). En plus, la structure try/catch est particulière, et casse le modèle standard de programmation structurée (séquence/condition/boucle).

07/12/2016, 23h01
benoit256255

À 15:00 heure de Montréal, je peux dire que j'ai réussi mon TP.

Il me reste des petites choses à faire dont la validation des textfields le point de départ de la discussion :)

Tu me recommandes quel méthode pour valider que l'usagé entre des valeurs purement numériques ?

Et des petits bug d'affichage de données lorsque d'autres données sont modifiées.

Merci :)
08/12/2016, 06h00
joel.drigo

Citation:

Envoyé par benoit256255

Tu me recommandes quel méthode pour valider que l'usagé entre des valeurs purement numériques ?

Je t'ai déjà répondu à ce sujet : normalement, on utilise un DocumentFilter, mais tu peux le faire en passant par la méthode keyTyped de KeyListener (voir exemple dans message précédent), dans le même KeyAdapter que tu as déjà écrit pour la synchro.

Merci Joel pour la validation pour mes JTextField

Code:

1
2
3
 
if (angleEnText.length() > 0 && angleEnText.length() <= 4) {
   if (angleEnText.matches("-?\\d+")) {

Maintenant, il me reste une validation à faire encore avec JTextField mais avec des doubles et integers...

J'utilise toujours un addKeyListener

Extrait de mon code :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
echelle.addKeyListener(new KeyAdapter() {
            @Override
            public void keyReleased(KeyEvent e) {
                String echelleEnText = echelle.getText();
 
                //je n'ai pas de limite sur le nombre de valeurs numériques...
                if (echelleEnText.length() > 0) {
 
/*Ici j'essaye d'utiliser la même logique plus haut du style :
des valeurs numériques seulement où le . peut être là comme il ne peut être là ET ensuite d'autres valeurs numériques sont acceptées.
*/
                     if (echelleEnText.matches("\\d+.?\\d+")) {

On dirait que le KeyListener n'est pas pratique pour construire un double...avec des validations....