Discussion :

[#define]

Bonjour,

Je fais mes premiers pas avec "Eclipse Neon.1 Release (4.6.1)" après avoir (un peu) utilisé NetBeans 8.1.

En ajoutant sur une "JFrame Form" (dans cet ordre), un bouton et ensuite un label, on obtient le code ci-après.
En ajoutant ensuite un "actionPerformed" sur le bouton visant à modifier le label, cet ajout est impossible par l'autocomplétion parce que le JLabel est défini plus bas.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
private void initialize() {
 frame = new JFrame();
 frame.setBounds(100, 100, 450, 300);
 frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 frame.getContentPane().setLayout(null);

// 1. Dépose du bouton
 JButton btnNewButton = new JButton("New button");
 btnNewButton.addActionListener(new ActionListener() {
  public void actionPerformed(ActionEvent e) {
  lblNewLabel.xxxxxx  // Pas d'autocomplétion possible.
  }
 });

 btnNewButton.setBounds(126, 37, 117, 29);
 frame.getContentPane().add(btnNewButton);
		
 // 2. Dépose du label
 JLabel lblNewLabel = new JLabel("New label");
 lblNewLabel.setBounds(155, 102, 61, 16);
 frame.getContentPane().add(lblNewLabel);
 }
}

Il faut donc modifier le code comme suit, en déplaçant vers le haut les définitions du JButton et du JLabel.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
JButton btnNewButton = new JButton("New button");
JLabel lblNewLabel = new JLabel("New label");
		
// 1. Dépose du bouton
btnNewButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
   lblNewLabel.xxxx // Autocomplétion possible.

   }
 });
 btnNewButton.setBounds(126, 37, 117, 29);
 frame.getContentPane().add(btnNewButton);
		
 // 2. Dépose du label
 lblNewLabel.setBounds(155, 102, 61, 16);
 frame.getContentPane().add(lblNewLabel);
 }
}

Est-on impérativement obligé de procéder de la sorte, à savoir, déplacer manuellement les définitions des composants ?
Je n'ai pas ce problème avec NetBeans.

Merci pour vos réponses.

[Tcharl]

Hello,

Si si, tu as la même problème avec Netbeans: en Java, les variables doivent être déclarées avant d'être consommées, c'est une règle.

Tu peux:
* Soit mettre les composants sous forme d'attributs de classe
* Soit mettre ton listener plus bas dans la méthode

Cordialement,

[#define]

Merci Tcharl pour la réponse.

J'avais bien compris la notion de portée et donc de la raison de ce blocage.

Mais pour être précis dans le cadre de mon incompréhension :

- NetBeans ne trouve pas l'autocomplétion, mais affiche toutefois la liste des méthodes autorisées. En forçant l'affichage de l'autocomplétion (CTRL+Espace), il accepte le code par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 jLabel1.setText("Message");

et la compilation peut s'effectuer sans problème, malgré le fait que le bouton ait été déposé sur la jFrame avant le label. D'ailleurs, les variables autogérées par NetBeans sont déclarées dans les dernières lignes du code.

- Eclipse ne propose rien du tout dans l'autocomplétion. En forçant le code, la compilation ne peut donc logiquement pas s'effectuer. Sauf à déplacer manuellement les variable de bouton et de label avant leur utilisation par le label.

[joel.drigo]

Salut,

Je ne sais pas ce que fait NetBeans, mais s'il permet réellement de placer une variable hors portée par complétion, ou de faire la complétion des méthodes ou attributs dessus, c'est absurde, car le code est de toute manière non compilable. A noter également qu'il le devient (compilable) quand tu déclares la variable avant ta classe anonyme parce que la variable est effectively final et que tu es en Java 8. En Java 7 et avant, tu n'aurais même pas pu écrire/compiler ce que tu as écrit (dans déclarer la variable explicitement final).
Eclipse ne permet pas la complétion qui n'est pas à portée, et ne propose pas de completion des méthodes sur une variable inconnue, parce que ça ne compilera pas. En quelque sorte, le parti pris est de laisser corriger le code avant, plutôt que de permettre d'écrire quelque chose dont on sait que ça ne compilera pas. Ce qui est plutôt une bonne chose, amha.

[#define]

@joel.drigo
Je conçois également qu'Eclipse est plus logique sur ce point là et c'est la raison de ma remarque par comparaison à NetBeans.

Merci pour vos réponses.