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.

[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)