problème avec Android requestFocus()

Question

Ci-dessous est le morceau de code que j'ai écrit pour transférer le focus d'un texte d'édition à l'autre, mais le problème que j'ai eu avec cette implémentation est le focus , et se déplace tout d'un coup à la prochaine édition text.So, je ne pouvais pas en mesure d'entrer quoi que ce soit, puisque l'accent est pas du tout rester que le texte d'édition particulier ..

 
//some code comes here 
// gun_pistolNotes and gun_pistolModel are two diff. editText 
...... 
...... 
    gun_pistolNotes.setOnEditorActionListener(new OnEditorActionListener(){ 
    @Override 
    public boolean onEditorAction(TextView view,int actionId, KeyEvent event){ 
    if(actionId == EditorInfo.IME_ACTION_UNSPECIFIED){ 
     gun_pistolModel.requestFocus(); // moves to this edittext and suddenly moves to another editext 
     return true; 
    } 
    return false; 
    } 
    }); 

...... 
...... 
//some code comes here 

toute aide est appréciée.

Merci d'avance.

Answer 1

Je réalise que c'est une vieille question, mais je faisais face à un problème similaire après des heures de frustration, j'ai trouvé le problème, alors je pensais que je devrais le poster ici au cas où quelqu'un d'autre aurait besoin.

Dans mon code, j'ai réalisé que pour une raison quelconque, en spécifiant android:inputype sur mon edittext était à l'origine de ce comportement de "saut". Donc, si j'ai EditText1 avec android:inputType="textCapSentences" dans le fichier XML, l'appel requestFocus() sur EditText1 le met en surbrillance brièvement avant de déplacer le focus sur la vue suivante.

Je ne suis pas sûr si c'est un bug dans Android ou si c'est en effet quelque chose d'autre qui me manque. J'ai essayé de mettre inputType par programmation & dans divers points dans mon code, avec setInputType() mais cela n'a pas fonctionné pour moi. Donc pour l'instant je viens de supprimer l'attribut inputType & requestFocus() fonctionne comme il se doit.

Answer 2

Je suis confronté exactement au même problème. Je peux confirmer l'affirmation de Kre8 selon laquelle ce comportement ne se produit que s'il y a un type d'entrée spécifique (dans mon cas, textNoSuggestion/singleLine). Je vais expliquer plus tard pourquoi c'est probablement le cas. J'ai décidé d'analyser ce qui se passe à l'intérieur de la vue. Après tout, je peux dire que ce n'est pas un bug juste une constellation malheureuse peut-être :). L'EditText pour lequel vous avez demandé le focus, le reçoit correctement.

Votre premier problème peut-être non reconnu est que l'éditeur EditorActionListener est appelé deux fois. Une fois pour la clé et une fois pour la baisse. Je ne connais pas l'effet de votre vérification de l'actionId, de sorte que peut-être conserve votre code d'être exécuté deux fois.

J'ai donc appelé à tort dans ma demande de solution se concentrer sur l'événement de clé ACTION_DOWN. L'EditText a reçu le focus correctement, MAIS sur l'événement ACTION_UP à venir, qui est en quelque sorte interprété par l'EditText récemment mis au point, le focus a été renvoyé immédiatement au focus EditText précédemment envoyé car il est dans la recherche de focus la prochaine réception.

Donc je suppose que maintenant le type d'entrée a un effet parce que, si l'EditText est dans un mode multiligne, la touche d'entrée n'enverra plus le focus.

Ma solution de travail finale ressemble à ce que:

passwordEditText.setOnEditorActionListener(new OnEditorActionListener() { 

    @Override 
    public boolean onEditorAction(TextView v, int actionId, KeyEvent event) { 
    if (event != null && event.getKeyCode() == KeyEvent.KEYCODE_ENTER && v == passwordEditText) { 
     if (event.getAction() == KeyEvent.ACTION_UP) { 
     if (userEditText.length() > 0 && passwordEditText.length() > 0) { 
      login(); 
     } 
     if (userEditText.length() == 0) { 
      userEditText.requestFocus(); 
     } 
     } 
     return true; 
    } 
    return false; 
    } 
}); 

Espérons que cela fonctionne aussi bien pour vous :)

Edit: J'ai oublié de signaler, que le type d'entrée du EditText peut être CHOISI comme vous le souhaitez, car la méthode onEditorAction gère les deux, haut et bas.

Answer 3

Android a toujours pris en charge le codage d'une hiérarchie "haut/bas/droite/gauche" pour les vues. Cela a été fait à l'origine pour les appareils de trackball comme le G1.Je ne pense pas que vous avez trouvé un bug - mais nous pourrions vérifier en regardant une source SDK. Pour les personnes confrontées à un problème similaire, vous pouvez essayer d'appeler setNext ** Focus (...) sur la vue qui doit être "floutée", puis générer un événement pour passer au "champ suivant". Cela peut être fait à la fois en XML et pendant l'exécution. Avez-vous essayé?

Voir Voir # focusSearch (int) et View # setNext ** Focus (int). Le SDK suggère que dans votre onEditorAction (...), vous pouvez écrire quelque chose comme:

... if (userEditText.length() == 0) { hostGameBtn.setNextFocusDownId (R.id.myUserEditTextViewID); hostGameBtn.focusSearch (View.FOCUS_DOWN); } ...

Answer 4

J'ai trouvé cela a fonctionné de manière fiable:

 field1Text.setOnEditorActionListener(new TextView.OnEditorActionListener() { 
     @Override 
     public boolean onEditorAction(TextView textView, int i, KeyEvent keyEvent) { 
      if ((i == EditorInfo.IME_ACTION_UNSPECIFIED) && (keyEvent != null) && 
        (keyEvent.getKeyCode() == KeyEvent.KEYCODE_ENTER)) { 
       if (keyEvent.getAction() == KeyEvent.ACTION_DOWN) { 
        return true; 
       } 
       i = EditorInfo.IME_ACTION_DONE; 
      } 
      if (i == EditorInfo.IME_ACTION_DONE) { 
       field2Text.requestFocus(); 
       return true; 
      } 
      return false; 
     } 
    }); 

Ce clavier gère à la fois entrer et en cliquant sur le bouton d'action dans le clavier virtuel. La chute de la logique est due au fait que je fais d'autres choses à la branche requestFocus, que j'ai omise ici parce qu'elles ne font pas partie du problème.