Entrée clavier / GUI / Console

Bonjour,

Voici mon problème. J'ai une interface graphique en Swing, contenant un Jlabel. J'aimerai que ce Jlabel se mette a jour en fonction des entrées clavier.
J'ai donc procédé de la manière suivante :

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 29 30 31 32 33 34 35 36 37 38 39

new SwingWorker() { String res=""; public Object construct() {   while (true) {   BufferedReader clav = new BufferedReader(new InputStreamReader(System.in)); try { res = clav.readLine(); publish(res); } catch (IOException e) { System.out.println(e); } } }     public void finished() { lfdNr.setText(res);       protected final void publish(final Object value) { SwingUtilities.invokeLater(new Runnable() { public void run() { process(value); } }); }   protected void process(Object value) { lfdNr.setText(res); cadImg.setLfdNr(Long.parseLong(res)); gButton.setLfdNr(Long.parseLong(res)); } }.start();

---

Ceci marche plutôt bien, a une exception pret : l'entrée du clavier n'est prise en compte que si j'ai le focus sur la console, ce qui m'oblige a switcher entre mon interface graphique pour voir le resultat, et ma console pour ecrire du texte.
Comment pourrai-je faire, pour que l'utilisation du clavier soit prise en compte quand je suis sur ma GUI, et non uniquement sur ma console ?

Merci d'avance

Cordialement

Je crois que je vais pouvoir me repondre moi-meme en disant : "Il faut utiliser les KeyListener (abruti ! ) "
Mhh je vais préciser ma question en fait : c'est pas vraiment l'entree clavier que je veux lire, mais j'ai un lecteur de code barre connecté, qui renvoit en String le code lu. Je peux quand meme m'en sortir avec KeyListener ?

Me revoila :)
J'ai donc ajouté un KeyListener sur mon Jlabel. Le probleme etant que qaund je clic quelque part sur mon interface, ce Jlabel pert le focus et par consequent, le listener ne marche plus.
Pour mon programme il faudrait que le listener marche en permanence, mais que le clic sur l'interface soit tout de meme possible.
Existe-t-il un moyen d'y parvenir ?

Merci

Ce genres de trucs n'est pas franchement réalisable, trop de possibilités, puis tu risques de tomber sur un bug à tout moment.

Sérieusement, je me demande si tu ne passerait pas moins de temps à coder directement la récupération des données de ta douchette.

Genre en utilisant ce genre de choses en supposant que ton lecteur est branché par USB: http://lxer.com/module/newswire/ext_link.php?rid=116455.

L'avatage étant que tu as juste un thread à lancer pour écouter sur ton port USB, puis de répercuter les infos entrantes sur ton interface graphique. Et comme ça plus besoin de gros hacks Swing à la mords moi le noeud.

Bonjour,
Merci pour ta réponse. Mais es-tu sur de m'avoir envoyé le bon lien ? J'avais l'impression qu'il n'avait pas de lien direct avec mon problème. Qu'entends-tu par "coder directement la récupération des données de ta douchette" ? En fait la douchette que j'utilise actuellement se branche sur le port ps2 du clavier, et marche exactement comme un clavier. Si j'ouvre l'editeur de texte, et scanne un code barre, le code apparait. Seulement j'aimerai integrer ce code lu a mon programme java, et surtout rendre ce code visible dans mon interface graphique.
Le fait de lancer un thread "ecoutant" la lecture du code barre, c'est ce que je pensais faire avec le Swingworker. Le probleme etant que vu la manière dont la lecture marche actuellememt, je susi obligé de repasser sur la console.

Effectivement je me suis un poil gouré dans le lien, voilà la bonne version: http://inf.ntb.ch/infoportal/help/in...tal/tools.html.

Le problème c'est qu'elle suppose que tu possède une douchette USB (ce qui est plutôt facile à trouver et pas trop trop cher). De ce fait tu découples le coté saisie douchette et entrée dans l'interface vu qu'avec cette api tu peux intercepter les flux en provenance d'un port USB.

D'accord ! Mais je dois avouer, sans vouloir faire mon difficile, que c'est une solution qui ne plait qu'à moitié. Ne serait-il pas envisageable dùtiliser un GlassPane, avec une KeyListener, qui du coup, capte toutes les entrées clavier ? Ou ce GlassPane peut-il aussi perdre le focus ?

Citation:

---

Envoyé par SebastianPx

D'accord ! Mais je dois avouer, sans vouloir faire mon difficile, que c'est une solution qui ne plait qu'à moitié. Ne serait-il pas envisageable dùtiliser un GlassPane, avec une KeyListener, qui du coup, capte toutes les entrées clavier ? Ou ce GlassPane peut-il aussi perdre le focus ?

---

Ce glasspane fera perdre le focus des autres éléments de ton application, et puis tu auras du mal à tout récupérer.

Vraiment récupérer directement les données depuis le port est probablement la meilleure des possibilités, la plus propre. Le reste n'est que dirty hack.

Salut,


Une solution serait d'agir directement sur l'EventQueue qui gère tous les évènements de l'application.

Par exemple comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class MyEventQueue extends EventQueue {   @Override protected void dispatchEvent(AWTEvent event) { // On intercepte l'evenement : if (event instanceof KeyEvent) { System.out.println("KeyEvent recu : " + event); } // Puis on appelle la méthode parente qui effectuera // le traitement par défaut ;) super.dispatchEvent(event); } }

---

Il suffit ensuite de le passer comme queue principale :

Code:

---

Toolkit.getDefaultToolkit().getSystemEventQueue().push(queue);

---

a++

Le problème état de savoir si l'entrée vient de la douchette ou vient d'une autre source, mais bon là on ne connait pas trop le contexte.

Merci pour ta réponse adiGuba.
L'entrée vient de la douchette, un scannage de code barre a lieu de manière reguliere et doit donc mettre a jour ce Jlabel. Mais en meme temps, l'utilisateur doit avoir la possibilité d'interagir sur l'interface ( ou plus precisement d'enregistrer des erreurs liées au produit scanné ).
Je vais donc m'interesser de plus près a la possibilité d'agir sur l'event-queue.

Sinon tu peux tout simplement remplacé le JLabel par un JTextField... Il suffira de le sélectionner avant d'utiliser la douchette ;)

a++

Le problème en ce qui concerne mon projet est que le scannage d'objet se fait de manière reguliere, et surtout automatique. Il doit donc être possible d'utiliser l'interface pour indiquer une erreur, tout en continuant, en arriere plan, d'afficher les numéros de pièces scannées. J'espere avoir réussi a être a peu pret comprehensible :)

C'est pour ça que la solution de lire directement les données arrivant d'un port via un thread totalement destiné à ça me semble être la solution la plus fiable et la plus pérenne. Et puis des adapteurs PS2/USB ça doit quand même se trouver, et pour pas des masses.

Oui c'est très clair...

En fait le gros problème serait de déterminer l'origine des éléments reçu, afin de faire la distinction entre le clavier et la douchette. Sauf erreur de ma part, la douchette doit "simuler" la saisie de caractère, et c'est donc difficilement différentiable d'une saisie clavier par l'utilisateur...

:arrow: Essayes toujours d'afficher les KeyEvent généré par la douchette, et de les comparer aux touches équivalentes du clavier pour voir s'il y a un moyen quelconque de les différencier...


Pour finir juste une remarque sur mon code précédent : plutôt que de passer par l'EventQueue il serait plus propre de passer par le KeyboardFocusManager :

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

// Le label avec son KeyListener final JLabel label = new JLabel(); label.addKeyListener(new KeyAdapter() { @Override public void keyTyped(KeyEvent e) { // ... } });   final KeyboardFocusManager keyboardManager = KeyboardFocusManager.getCurrentKeyboardFocusManager(); keyboardManager.addKeyEventDispatcher(new KeyEventDispatcher() { @Override public boolean dispatchKeyEvent(KeyEvent e) { // Ici on peut traiter le KeyEvent AVANT qu'il ne soit propagé if ( /* on arrive à détecter que cela vient de la douchette */ ) { // On envoit le KeyEvent vers le JLabel : keyboardManager.redispatchEvent(label, e);   // On retourne 'true' pour indiquer que l'on a traité le KeyEvent. return true; }   // Sinon on retourne 'false' pour propager le KeyEvent normalement return false; } });

---

:arrow: Le gros problème étant d'arriver à détecter la source exacte des KeyEvent...

a++

A la limite la differenciation entre clavier / douchette m'importe peut etant donné que dans mon cas il y a uniquement une douchette, et pas de clavier. Par contre en passant par un KeyboardFocusManager, si la fenetre principal n'a pas le focus ( une autre Jframe s'ouvre pour donner la possibilité d'enregistrer une erreur ), l'enregistrement par la douchette ne marchera plus, non ?
Ce qui obligerait, pour scanner un produit a etre sur la fenetre principale ( si je ne me trompe pas ). Ceci est pour moi problematique, vu qu'il faudrait que l'enregistrement de produit par la douchette marche en continue, qu'une autre Jframe soit ouverte ou non. Désolé d'etre aussi chiant dans mes exigences !
Ne serait-il pas possible que le Jlabel ou jtextfield garde toujours le keyboardfocus ?

Cela marchera tant que ton application aura le focus quel que soit la fenêtre...

Maintenant s'il s'agit de fenêtres apparenant à d'autres applications alors cela ne marchera pas et il faudra passer par un accès direct (voir la solution de sinok)

a++

D'accord, je vous remercie ! Je mettrai l'avancement de mes travaux sur ce topic, c'est peut-etre susceptible d'interesser d'autres personnes.

Bonjour,
désolé de remonter ce vieux topic, mais je n'ai pas trouvé mieux sur le net et je suis actuelement bloqué sur un problème quasi identique.

J'ai tester le code et cela fonctionne parfaitement or je pense que lorsqu'on scann une carte magnétique, elle envoie une chaine de caractère. J'aimerais donc savoir comment m'y prendre pour récuperer la chaine de caractère.

Merci d'avance