Demande d'aide pour findComponentAt

**patdu26** · 14/01/2021, 19h24

bonjour à tous,

je poursuis mon élaboration d'une interface graphique gérant des composants sur une "grille perso".

Comme me l'a suggéré gervais.b, j'essaie de mettre en œuvre une approche MVC et notamment un module "controle" qui reçoit un appel de souris éventuel sur la grille, qui est un "MouseListner" unique. (Les composants déposés sur cette grille sont sans listener).

Quand je clique sur la grille, je teste mes composants avec la méthode "findComponentAt".
En effet, cette méthode renvoie de composant lui-même si il contient effectivement les coordonnées (x,y) du clic, passées en paramètres, et sinon, elle renvoie "null".

Mon interface ressemble à ça :
Nom : ecran1.png
Affichages : 118
Taille : 37,7 Ko

Nom : ecran1.png
Affichages : 118
Taille : 37,7 Ko

Pour tester la méthode, je fais un essai avec le composant "r_5", et le code :

Code :

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

1
2
3
4
5
6
public static void clic_sur_grille(Point p) {
		System.out.println("je clique sur la grille sur la grille : " + p);
 
			Component cible;
			cible = Grille.recept[5].findComponentAt(p);
			System.out.println(" le composant détecté est  : " + cible);

, et je clique ensuite "un peu partout" sur mon interface...

Je pensais que, lorsque je clique sur la grille, ailleurs que sur le composant "r_5", j'allais récupérer "null" et que si je clique sur le composant "r_5", ce dernier serait détecté et affiché dans la console de contrôle.

La difficulté est que cela fonctionne uniquement pour un clic correspondant à la surface du composant, mais à partir des coordonnées (0,0) de la grille, alors que "r_5" est bien localisé en (384,204). Le problème est représenté ci-dessous :
Nom : ecran2.png
Affichages : 127
Taille : 38,8 Ko

Nom : ecran2.png
Affichages : 127
Taille : 38,8 Ko

Ma stratégie de détection des composants par le module de contrôle étant basée sur une grille "unique sur écoute" et une déduction par traitement du composant visé,

quelqu'un peut-il me dire pourquoi cette détection basée sur les coordonnées (0,0), et ce, quel que soit le composant et où qu'il se situe, même si cette détection respecte bien la surface du composant???

Si pas de solution, quelle nouvelle statégie peut-être possible pour ce type d'application??

Merci à tous ceux qui prendront la peine d'y réfléchir et de me répondre....

**bouye** · 14/01/2021, 22h47

Sur quel composant as-tu installe ton listeneur ? Vérifie que tu l'as seulement installe sur la grille.
Et qu'est ce que Grille.recept[5] ?

**gervais.b** · 15/01/2021, 14h41

Bonjour,

Avez-vous décidé d'utiliser des JComponent pour chaque "forme" ou peignez vous complètement la grille ?

Par defaut, les composants se trouvent dans un rectangle qui est toujours en 0, 0, c'est le layout manager qui est responsable de leur position. Ce qui veux dire que si vous utilisez Graphics pour déleguer le dessin à vos formes ça ne pourra jamais fonctionner car 1) les composants ne sont probablement pas ajoutés au container (bleu) et 2) tous les composants pensent être en 0, 0.

Soit vous devez boucler sur vos composants et faire une sorte de translation de vos coordonnées, soit vous devez adapter les "bounds" de chaque composant et les ajouter au container.

Je partirais toujours pour l'option de tout peindre et donc rechercher manuellement le composant après avoir adapté les coordonées.

Code :

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

1
2
3
4
5
6
7
8
9
 
// Je peux me tromper dans les "translations" et le test mais vous avez l'idée.
for (Cellule cell : cellules) {
  int x = p.x - cell.x;
  int y = p.y - cell.y;
  if ( x < p.width && y < p.height ) {
    return cell; // Cette Cellule contient le click.
  }
}

**patdu26** · 15/01/2021, 18h00

Envoyé par bouye

Sur quel composant as-tu installe ton listeneur ? Vérifie que tu l'as seulement installe sur la grille.
Et qu'est ce que Grille.recept[5] ?

La grille est un "JComponent", qui prend la dimension du contentPane et occupe l'emplacement "Center" de ce dernier.

A la constructiion, cette grille créé et positionne le nombre de "recept" passés en paramètre dans le constructeur de cette grille ( nb sur x, nb sur y).
Les éléments de type "Recept" ne sont que des JComponent de couleur et de taille fixes.

Tout se passe bien, la grille est impeccable pour moi, et les coordonnées de "recept" sont bien différentes et non nulles, comme on peut le voir sur la capture d'écran.
(voir coordonnées sur les captures d'écran) puisque d'ailleurs, ils sont bien positionnés à des endroits différents et non superposés en (0,0)

C'est bien cette grille qui a uniquement le listener et les coordonnées du point de clic "p" sont cohérentes à chaque fois dans la console.

MAis en effet, les coordonnées prises en compte dans le "getComponentAt" sont forcémment (0,0) car la détection est ok uniquement dans la zone décrite sur la photo, qui commence en (0,0) de ma grille et reste valide sur la surface qui correspond à celle d'un récept.....

Vraiment étrange pour moi.....je continue à essayer de comprendre. Merci pour vos idées et quoi qu'il en soit, si je trouve, je vous indiquerai la nature de mon erreur et je cliquerai le "résolu".... Merci pour votre intervention.

**patdu26** · 15/01/2021, 18h14

Envoyé par gervais.b

Bonjour,

Avez-vous décidé d'utiliser des JComponent pour chaque "forme" ou peignez vous complètement la grille ?

Par defaut, les composants se trouvent dans un rectangle qui est toujours en 0, 0, c'est le layout manager qui est responsable de leur position. Ce qui veux dire que si vous utilisez Graphics pour déleguer le dessin à vos formes ça ne pourra jamais fonctionner car 1) les composants ne sont probablement pas ajoutés au container (bleu) et 2) tous les composants pensent être en 0, 0.

Soit vous devez boucler sur vos composants et faire une sorte de translation de vos coordonnées, soit vous devez adapter les "bounds" de chaque composant et les ajouter au container.

Je partirais toujours pour l'option de tout peindre et donc rechercher manuellement le composant après avoir adapté les coordonées.

Code :

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

1
2
3
4
5
6
7
8
9
 
// Je peux me tromper dans les "translations" et le test mais vous avez l'idée.
for (Cellule cell : cellules) {
  int x = p.x - cell.x;
  int y = p.y - cell.y;
  if ( x < p.width && y < p.height ) {
    return cell; // Cette Cellule contient le click.
  }
}

pour le moment, je ne vois pas comment faire sans composant.

Vous parlez "d'adapter les coordonnées", mais pourquoi faudrait-il le faire? La grille contient les composants, qui ont leurs coordonnées propres valides, et le seul listener?....

Les recepts sont donc des vrais "JComponent", que la grille créé et dispose de manière ordonnée. Cela fonctionne et les coordonnées sont cohérentes car la grille est nickel à l'écran.
Quand je clique, les coordonnées renvoyés par le point "p" sont tout à fait cohérentes également.
Ce qui m'échappe, c'est que les composants orange, (recept_0, recept_1,.... recept_n) qui sont à leur vrai emplacement prévu, la méthode "getComponentAt" s'obstine à ne les détecter que sur la zone qui débute en (0,0) de la grille , sur une surface équivalente à la surface d'un "recept"...

Je me doute que la méthode fonctionne et que quelque chose m'échappe, mais quoi..... mystère...

En tout cas, merci d'avoir pris du temps pour ma question!

**patdu26** · 16/01/2021, 17h33

Bonjour à tous, (si d'autres que moi lisent ce message of course....)

j'ai regardé la java doc sur les deux méthodes "findCompoenetAt()" et getComponentAt().
Ces deux méthodes un peu cousines, permettent théoriquement de situer un composant sur un Jpanel par exemple.

J'ai fait un simple JPanel, avec un simple carré de couleur au milieu.

J'ai testé les deux méthodes avec le clic de souris entré en paramètre type Point.
J'ai testé les deux méthodes avec le clic de souris entré en paramètre de type (x, y).
J'ai même testé les deux méthodes avec des paramètres (x, y) en "dur", parfois dans la zone du composant central, parfois en dehors.

Le comportement est toujours le même :

La détection se fait sur une surface égale à celle du composant, ça c'est bon!!, mais détecté là où il ne se situe pas, c'est à dire à partir du point (0,0) de mon Panel...

Ça m'étonnerait que des méthodes ne fonctionnement pas. Tout à l'air ok, mais impossible à utiliser?????

Je doit devenir un peu fou et ne pas voir l'évidence.... Écrire est peut-être déjà un début de thérapie, mais bon dur de pas comprendre la méprise.....

Je vais devoir envisager un plan B, et tester moi même au clic, tous mes composants sur le panel pour savoir si ce clic correspond à un de mes composants....
Faisable, mais frustrant de ne pas comprendre pourquoi aucun moyen de faire fonctionner ces méthodes mises à disposition.....

Bravo à celui qui aura eu la patience d'aller jusqu'au bout!!

**patdu26** · 16/01/2021, 19h26

merci à gervais.b pour le bout de code.

Je l'ai modifié car sinon il y a des problèmes pour les cas où la différence est négative.

J'ai fait ça, qui n'est pas forcément performant au niveau rapidité, mais ça fonctionne. (Les commentaires sont parfois pas totalement vrais par rapport à x ou y mais ca fonctionne).

De plus, la vitesse n'a ici qu'un importance relative...

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
public void mouseClicked(MouseEvent e) {
				int mx = e.getX();
				int my = e.getY();
 
 
 
				for (Composant_17 size : comp) {
 
 
					 System.out.println("clic en x : "+ mx + "et y : " +  my);
 
 
					  if ( mx > size.getX()  &&  mx < (size.getX()+size.getWidth())){
 
								  	if (my > size.getY() && my < size.getY()+size.getHeight()) {
								  			System.out.println("on est dedans!!" +"\n" );
								  	}
							  		else System.out.println("Caramba!!!! les y sont mauvais!!\n");
					  }
					  else System.out.println("Caramba!!!! les x sont mauvais!! \n");
					  }

Si vous voyez une amélioration évidente ou une imperfection de principe, je suis preneur bien sur...

**gervais.b** · 18/01/2021, 10h39

Bonjour,

Heureux de voir que vous avez trouvé une solution à votre problème. Mais pour trouver une solution au vrai problème de findComponentAt, pourriez-vous nous partager le code du conteneur (bleu) et celui des "recept" (orange) ?

Merci.

**patdu26** · 19/01/2021, 09h37

Envoyé par gervais.b

Bonjour,

Heureux de voir que vous avez trouvé une solution à votre problème. Mais pour trouver une solution au vrai problème de findComponentAt, pourriez-vous nous partager le code du conteneur (bleu) et celui des "recept" (orange) ?

Merci.

Bonjour, comment vous faire parvenir la source sans mettre toutes les classes directement dans un message? J'ai pensé à utiliser le dépot des sources, mais cela a peu d'intérêt pour les visiteurs qui ne sont pas au courant de la démarche de déblocage sur une source en cours d'étude?... Je peux vous compresser les classes si je peux vous les adresser bien sur. Je ne suis pas au fait de la procédure ici.

**gervais.b** · 19/01/2021, 10h24

Le désavantage du dépot est qu'il sera mise à jour et n'auras effectivement plus d'intérêt pour un éventuel visiteur.

Peut-être pourriez-vous zipper et attacher les sources dans cette discussion.

**patdu26** · 19/01/2021, 11h42

Envoyé par gervais.b

Le désavantage du dépot est qu'il sera mise à jour et n'auras effectivement plus d'intérêt pour un éventuel visiteur.

Peut-être pourriez-vous zipper et attacher les sources dans cette discussion.

bonjour,

je vous ai fait un fichier compressé.

N'hésitez pas à me faire un retour sur toutes les incohérences que vous trouverez...

**gervais.b** · 19/01/2021, 14h44

Ok, merci.

Pour connaître les enfants d'un conteneur, il faut le demander au conteneur, pas à un des enfants.

Votre problème avait presque été détecté par bouye, il s'agit de la ligne 27 dans Controle:

Code :

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

cible = MyWindow.g1.recept[5].getComponentAt(p);

Avec cette ligne vous accédez au 6ième Recept de votre tableau. Celui-ci ne contenant aucun composant, il vous renvoie null ce qui n'aide pas au debugage.

La solution est simplement de demander au conteneur, g1, quel enfant est contenu à la position voulue (et non pas à un de ces enfants).

Code :

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

cible = MyWindow.g1.getComponentAt(p); // recept[5] à été supprimé

**gervais.b** · 19/01/2021, 14h45

Envoyé par patdu26

N'hésitez pas à me faire un retour sur toutes les incohérences que vous trouverez...

Je vois beaucoup d'autres choses qui me tracassent dans ce code (nommage, aucune encapsulation, accès statiques, ..). Mais ce n'est pas l'objet de votre question initiale.

**patdu26** · 20/01/2021, 08h06

Envoyé par gervais.b

Je vois beaucoup d'autres choses qui me tracassent dans ce code (nommage, aucune encapsulation, accès statiques, ..). Mais ce n'est pas l'objet de votre question initiale.

Merci gervais.b pour l'explication claire.
En effet, ma compréhension de la javadoc sur cette méthode n'était pas correcte et je n'aurais donc pas pus résoudre le dysfonctionnement de celle-ci....

Je suis également "hors des clous" pour le nommage, c'est vrai, et pas d'encapsulation non plus...
Cette dernière permet d'imposer des contrôles quand on entre une valeur de l'extérieur, pas le clavier par exemple, et ainsi se protéger de déclencher une exception. Quel est son intérêt pour des données qui transitent en interne dans un programme?

Concernant la déclaration statique des "recept" de la classe Grille, j'aurais préféré les déclarer liées à g1 uniquement, c'est à dire, à ma grille objet de la classe Grille, et non comme des éléments statiques de cette classe car cela me parait plus logique.
Cependant, comme mes éléments "recept" sont manipulés par d'autres classes, cette manière "à la hussarde" me permet de les avoir disponibles pour le code, alors que l'objet g1 n'est pas encore existant au démarrage du prg.... Mais suis-je clair?....

Quoi qu'il en soit un grand MERCI! pour votre réactivité et votre patience!!

A bientôt peut-être, car une avancée modeste reste un pas vers de nombreuses interrogations à venir....