Discussion :

[firgon]

Alors je ne rencontre pas le problème directement, mais certains de ceux qui ont essayé chez eux ont du mal avec mon appli parce qu'elle ne réagit pas de façon rapide.
Je n'ai aucune idée d'ou le problème pourrait venir. Je soupçonne une grosse erreur de débutant ou de lourdeur dans mon code.
J'utilise uniquement des mouseListener, puis des méthodes mouseClicked de base.
Les utilisateurs ont la sensation d'avoir à toujours appuyer 3 fois avant que le programme réponde. D'autres ont l'impression d'avoir à appuyer une fois pour réveiller le programme et une autre pour qu'il prenne en compte le click. Tout ça me parait bien étrange.
Est-ce que quelqu'un sait d'où cela peut venir?

D'avance merci de vos suggestions.

[tchize_]

première chose à faire, déterminer quelle est la différence entre chez toi et chez eux (os, système, carte vidéo, ...)

deuxième chose à faire, coté réactivité de l'interface, t'assurer que tu ne fais pas de traitement "lourd" dans l'interface graphique (exemple: un mouselistener ne devrait pas faire de gros calcul, il doit rendre la main le plus vite possible, sous peine de bloquer le reste de l'interface). Si t'as des traitement lourds à faire en réaction à un clic ou une action de menu, il faut les faire exécuter par un thread séparé.

D'un autre coté, t'assurer que tout les traitement graphiques sont bien effectués dans le thread de l'EDT pas un autre (le thread EDT c'est celui qui appelle tes listeners pour simplifier, c'est lui qui gère toute l'interface graphique et ce devrais être le seul qui modifie les composants swing).

Dernière chose, lancer l'application avec java.exe plutot que javaw.exe (sous windows) afin de récupérer d'éventuels stacktraces d'erreur.


Note: un appli graphique 'non réactive' se traduit normalement par une fenetre restant grise quand déplace une autre fenetre au dessus (ne se redessine pas, ou pas tout de suite), ce qui est signe de traitement lourds dans l'EDT, traitements qui n'y ont pas leur palce (voir point deux ci-dessus)

[firgon]

J'ai pas le sentiment que mes traitements soient "lourds", on est de l'ordre du setvisible() ou de la gestion de selection. mais de toute façon, il y a trop longtemps déjà que je repporte ce changement, il faut que je tiptopise ma gestion de l'EDT.

Ce qui me gène plus, c'est que d'après le ressenti des utilisateurs, c'est pas vraiment une appli qui se fige, on dirait plutôt que mes listeners "n'entendent pas" tous les clics ou au moins les premiers clics, hors j'ai aucun traitement de fond par ailleurs.

Bon je vais déjà soigner mes appels de l'EDT mais si vous avez d'autres idées, je suis preneur.

[tchize_]

sans code, c'est du d'aider

[firgon]

J'en ai tout à fait conscience.

En fait, comme il s'agit d'un problème général, je ne peux pas vous poster tout mon projet (non qu'il soit top secret, mais il est surtout longuet), je me demandait s'il n'y avait pas d'erreurs classiques de débutants de ce type.

Mais la première solution proposée me convient déjà très bien.

Tiens une question au passage, est-ce qu'il peut y avoir ralentissement parce qu'un trop grand nombre de listener est actif en même temps.

Chacun des objets affichés s'écoute lui même et peut réagir au clic, est-ce que ça peut généré des ralentissement ou une quelconque dégradation de performance ? Est-ce que j'ai intéret à regrouper mes écouteurs dans une seule et même classe, même pour des objets qui n'ont rien à voir?

[tchize_]

a moins d'avoir 500 listeners branché sur le même objet et qui font tous quelque chose, ca ne devrait pas poser problème. Vu que ca semble aléatoire et changer d'une machien à l'autre, la première chose est de récupérer les éventuelles exception dans la console, t'as peut etre un problème de concurrence dans le code qui n'apparait pas chez toi mais qui apparait chez tes client, un exception serait l'explication à la non exécution d'un listener.

[firgon]

Pas d'exceptions dans les sorties console... Ce serait trop beau.... Piste à refermer donc.

[adiGuba]

Salut,

J'ai pas le sentiment que mes traitements soient "lourds", on est de l'ordre du setvisible() ou de la gestion de selection.

Question : que fait ton application ?
Car d'après ce que tu dis elle se contente de mettre à jour l'interface sans rien faire derrière !?

Ce qui me gène plus, c'est que d'après le ressenti des utilisateurs, c'est pas vraiment une appli qui se fige, on dirait plutôt que mes listeners "n'entendent pas" tous les clics ou au moins les premiers clics, hors j'ai aucun traitement de fond par ailleurs.

Cela me fait quand même fortement penser à un blocage de l'EDT : les événements sont bien reçus et mis en pile mais ils ne sont pas traité de suite car l'EDT est bloqué...

Question : ce ressenti des utilisateurs, tu le ressens toi aussi ???

Ce que tu peux faire, c'est d'insérer dans ton application un JLabel avec un GIF animé en boucle (perso j'aime bien celui-ci : duke.running.gif) : si l'animation se fige c'est que l'EDT est bloqué


A noter que le problème pourrait également venir des méthodes paint()/paintComponent() si tu les as redéfinies...


Ce que tu peux faire également pour le debug c'est de définir un EventQueue personnalisé qui afficherait les évènements trop long :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class DebugEventQueue extends EventQueue {
 
	@Override
	protected void dispatchEvent(AWTEvent event) {
		long time = System.currentTimeMillis();
		super.dispatchEvent(event);
		time = System.currentTimeMillis() - time;
		if (time>250) {
			System.err.println("dispatchEvent trop long : " + time + " ms !");
			System.err.println("Event : " + event);
		}
	}
 
}

Qui s'installe comme ceci au début de l'application :

Code :

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

Toolkit.getDefaultToolkit().getSystemEventQueue().push(new DebugEventQueue());

Ceci va t'afficher tous les évènements qui prennent plus de 250ms à être traités...

Tiens une question au passage, est-ce qu'il peut y avoir ralentissement parce qu'un trop grand nombre de listener est actif en même temps.

Je ne pense pas... à moins que tu ne mettes un très grand nombre de listener sur le même événement du même composant...

Chacun des objets affichés s'écoute lui même et peut réagir au clic, est-ce que ça peut généré des ralentissement ou une quelconque dégradation de performance ? Est-ce que j'ai intéret à regrouper mes écouteurs dans une seule et même classe, même pour des objets qui n'ont rien à voir?

Non cela me semble tout à fait correct comme cela...

Mais j'en reviens aux traitements de ces listeners : ils se contentent tous de mettre à jour l'affichage ? Tu n'as aucun traitement métier ???


a++

[tchize_]

Pas d'exceptions dans les sorties console... Ce serait trop beau.... Piste à refermer donc.

les sorties consoles sont-elle bien affichées? si tes clients sont sous windows, et que ton appli est lancée avec javaw.exe (par défaut), alors il n'y a simplement pas de sortie console!

[firgon]

les sorties consoles sont-elle bien affichées? si tes clients sont sous windows, et que ton appli est lancée avec javaw.exe (par défaut), alors il n'y a simplement pas de sortie console!

Je redirige mes sorties err et out vers des fichiers txt et j'ai un fichier de log pour les exceptions interceptées.
Mais effectivement j'aurai pu oublier.

[tchize_]

Je redirige mes sorties err et out vers des fichiers txt

avec system.setErr() et system.setOut() ?

[Crossnine]

Ce qui me gène plus, c'est que d'après le ressenti des utilisateurs, c'est pas vraiment une appli qui se fige, on dirait plutôt que mes listeners "n'entendent pas" tous les clics ou au moins les premiers clics, hors j'ai aucun traitement de fond par ailleurs.

Bonjour

Je sais pas si ça peut être une piste, mais j'ai déjà rencontré ce genre de problème lorsque j'avais codé un jeu d'échecs.
L'utilisateur devait cliquer sur une pièce pour la déplacer. Seulement, j'avais cette sensation que sur certains clics ça ne fonctionnait pas. Le problème était tout bête (et n'en était pas un en fait ...) C'était juste que lorsque je cliquais, je faisais un léger déplacement avec la souris peu perceptible, ce qui correspondait à un autre événement à intercepter.

J'espère que ça pourra t'aider.

[firgon]

avec system.setErr() et system.setOut() ?

EDIT (phrase oubliée)... oui oui c'est ça...

C'était juste que lorsque je cliquais, je faisais un léger déplacement avec la souris peu perceptible, ce qui correspondait à un autre événement à intercepter.

C'est pas complètement idiot ça... Je bosse sur un portable, ça expliquerai que je rencontre pas le pb puisque chez moi, le bouton clic est séparé du déplacement...
Du coup, il faut que je code à l'identique MousePressed? C'est comme ça que tu t'en es sorti?

[Crossnine]

Bonjour,

C'est exactement ça.

J'ai appliqué le même traitement aux événements similaires et cette sensation que "certains clics ne fonctionnaient pas" à disparu.

En espérant que ça puisse t'aider.

Bonne journée

[tchize_]

l'idéal serait de commencer par fair des tests toi même sur les machines problématique. Si c'est un problème de souris qui bouge pendant le clic, l'utilisateur doit en général avoir beaucoup de mal avec son bureau windows alors (genre il déplace systématiquement les icone et les entrées du menu démarrer quand il veux cliquer dessus)

[Djobird]

Je confirme le problème, tu peux être quasi sur que ca vient de çà. Ce problème arrive très facilement, un léger décalage de la souris et ca suffit à interrompre un MouseClicked. Ce que tu peux faire :
Utiliser un acionListener à la place (pour les btn par exemple ca marche sans souci)
Utiliser MousePressed et mouseReleased mais plus chiant à mettre en place.