Discussion :

[jproto]

Bonjour,

Je cherche à intercepter un événement (le KeyEvent.VK_CUT) dans un contrôle (ici un JTextField).
L’ajout de listeners me permet d’ajouter du comportement sur cet événement, mais je peine à l’intercepter (je ne tiens pas à ce qu’il me supprime ma sélection).

Quelqu’un pourrait-il orienter mes investigations ?

Merci,
Chris.

[le y@m's]

As-tu essayé la méthode consume() de la classe KeyEvent (héritée de la classe InputEvent) ?

[jproto]

Ca ne semble pas fantastique (ou mal exploité).
Pour faire un peu bourrin, j’ai supprimé tous les listeners de mon contrôle.
Puis j’ai créé un simple listener destiné à tout intercepter.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
        for ( KeyListener l : jTextField1.getKeyListeners() )
            jTextField1.removeKeyListener(l);
 
        jTextField1.addKeyListener(new KeyAdapter() {
            public void keyReleased(KeyEvent ke) {
                ke.consume();
                cr.setText("keyReleased");
            }
        });

cr est juste un label qui me permet de constater que je suis bien passé dans mon listener.

Bref, je m’attendais à ce que mon contrôle ne soit plus bien vif.
Pourtant il vit encore .

[bbclone]

c'est quoi KeyEvent.VK_CUT?
juste pour dire que c'est pas CTRL + X

[jproto]

En fait, j’avais bon espoir que KeyEvent.VK_CUT réponde aussi bien à Ctrl+X qu’à MAJ+Suppr.

[bbclone]

En fait, j’avais bon espoir que KeyEvent.VK_CUT réponde aussi bien à Ctrl+X qu’à MAJ+Suppr.

pas du tout.
dans la doc:

/* for Sun keyboards */
/** @since 1.2 */
public static final int VK_CUT = 0xFFD1;

=> specifique a un materiel.
=> pas utiliser.

[jproto]

Manifestement, ta javadoc est plus complète que la mienne : http://java.sun.com/j2se/1.5.0/docs/...nt.html#VK_CUT

VK_CUT

public static final int VK_CUT
Since: 1.2
See Also: Constant Field Values

Mais je dois bien l'admettre, je n'en étais pas encore là. Merci pour l'info.

[bbclone]

LOL

ma javadoc c'est la meme que la tienne.
c'est un copy paste du code
regarde les
/* */
/** **/

je peut savoir qu'est ce que tu veut faire?

[bouye]

Vi, les claviers des stations UNIX (TX compris) en general et les claviers de Sun en particulier ont toujours eut pas mal de touche specialisees en plus (comme quoi Microsoft et Logitech n'ont rien invente).

Souvenez-vous que les evenements du clavier ne gerent que les touches claviers (ou une composition de touches clavier qui sont toutes identifiables par masquage), donc si vous voyez "CUT"* cela signifie bien la touche CUT*, pas une eventuelle combinaison de touches (KeyStroke - dont la definition est relativement dependant du systeme ou de l'application**) qui ferai la meme chose.

*Faudrai voir justement si ce genre de touche est supportee sur les claviers Office de Microsoft justement.

**Voir copier/coller dans Emacs et VI ce n'est pas juste CTRL+C, CTRL+V, etc...

[jproto]

Bien, en fait, je lutte toujours depuis quelque temps sur le fait de rendre inactive une zone texte sans perdre l’affichage de mon caret.

L’important, dans mon cas, est d’empêcher coûte que coûte l’utilisateur de modifier ma zone, mais il doit pouvoir la copier.

Dans l’immédiat, j’ai passé mon JTextField en inactif (non-editable), puis je lui ai restauré un affichage laissant croire qu’il est actif.

Cependant lorsque je passe un JTextField disable, je perds l’affichage de mon caret. Or, l’utilisateur s’en sert pour se repérer (lorsqu'il se déplace à l'aide du clavier).

Je tente donc de partir sur une autre solution.
J’ai repassé le champ en actif (editable), puis je lui ai retiré son KeyMap.

Code :

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

1
2
 
jTextField1.setKeymap(null);

Ainsi l’utilisateur ne peut pas directement modifier le contenu de ma zone (j’approche de la solution ...), et il peut toujours la copier.
Cependant, il peut aussi la couper. D’où mes tentatives pour intercepter l’action couper. Mais pour le moment sans grand succès.

[mikaMike]

Le fait de pouvoir couper le texte est lié aux InputMap il me semble? Pourquoi ne pas faire un remove sur le "Ctrl +X" ?

Tu dois aussi poouvoir regarder du côté de l'editor kit (DefaultEditorKit) qui définit les actions sur les composants éditables.

[jproto]

mikaMike,

Ta réponse m’a semblé de prime abord plutôt séduisante.

J’ai donc essayé ceci :

Code :

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

1
2
 
jTextField1.getInputMap().remove(KeyStroke.getKeyStroke(KeyEvent.VK_X, InputEvent.CTRL_MASK));

Mais je dois admettre qu’il s’en fout.

Quelque peu vexé, je suis parti sur une version moins fine :

Code :

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

1
2
 
jTextField1.getInputMap().clear();

Et bien je dois admettre que cela n’a toujours pas grand effet .

[jproto]

OK, je dois mal m'y prendre.

En effet, si j'écris :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
System.out.println("Avant");
for( KeyStroke k : jTextField1.getInputMap().allKeys())
    System.out.println(k.toString());
 
jTextField1.getInputMap().remove(KeyStroke.getKeyStroke("ctrl pressed X"));
 
System.out.println("Après");
for( KeyStroke k : jTextField1.getInputMap().allKeys())
    System.out.println(k.toString());

Je me rend bien compte que le avant comme arpsè mon remove(), j'ai toujours "ctrl pressed X" de pris en charge par le InputMap.

Idem avec le clear().

[mikaMike]

En effet, ça ne fonctionne pas, pour une raison que j'ignore... et que j'aimerais bien connaître.

Néanmoins, ceci bloque le Ctrl+X:
jTextField.getInputMap().put(KeyStroke.getKeyStroke("ctrl X"),"nothing");

"nothing" ne renvoit à aucune action en fait.

Pas super clean mais bon.

[jproto]

Je confirme, cela fonctionne, et je t'en remercie.

Ne tiens plus qu'à moi d'emballer cela de façon élegante.

Merci,
Chris.