2009-07-31 4 views
1

Je travaille sur une application iPhone assez simple pour résoudre l'équation quadratique, principalement parce que c'est tellement facile - au moins les concepts et les mathématiques!becomeFirstResponder ne respecte pas les paramètres du clavier

J'ai créé une interface dans Interface Builder qui a quelques étiquettes, 3 champs de texte (varAfield, etc.) et un bouton Résoudre. Les 3 champs de texte définis comme UITextFieldDelegate ont été configurés pour qu'ils affichent automatiquement le clavier "Numbers and Punctuation". Ce code est utilisé pour masquer le clavier, puis passer automatiquement à la variable suivante lorsque l'utilisateur tape sur la touche de retour (qui dit « Next », sauf pour la variable C qui dit « Done »

- (BOOL)textFieldShouldReturn:(UITextField *)theTextField { 
if (theTextField == varAfield) { 
    [varAfield resignFirstResponder]; 
    [varBfield becomeFirstResponder]; 
} 
if (theTextField == varBfield) { 
    [varBfield resignFirstResponder]; 
    [varCfield becomeFirstResponder]; 
} 
if (theTextField == varCfield) { 
    [varCfield resignFirstResponder]; 
} 
return YES; 
} 

Quoi qu'il en soit, le problème Le clavier se présente comme il se doit, cependant, il utilise un clavier ASCII au lieu de "Numbers and Punctuation" La deuxième fois que ça s'appelle, ça fonctionne comme il se doit, aussi, si je commence à partir de la variable A Quel que soit l'endroit où je déplace la première instance de getFirstResponder, la première (et la seule première) fois qu'elle est appelée dans l'application, elle ne se comporte pas correctement ..

Mise à jour: La fonction "firstFesRespondeur" (même en première instance) respecte toujours la touche de retour choisie, mais quel que soit le clavier défini, elle affiche toujours la clé "ASCII Capable". Alors que se passe-t-il? J'ai tout vérifié dans IB et il semble que ce soit correct ...

+0

Ok, j'ai fait d'autres tests dans le simulateur 3.0 et il semble fonctionner là-bas par rapport à la version sur laquelle je l'ai exécuté ... –

Répondre

0

Avez-vous essayé d'appeler d'abord un autre aspect de la fonction, d'abord, de sorte que lorsque vous l'appelez dans votre champ de texte, ce n'est pas la première fois? Par ailleurs, les deux premiers resignFirstResponders sont redondants. Ils pourraient même être ce qui fait que le bug soit révélé.

+0

hmm, je ne savais pas si c'était redondant ou non.Quoi qu'il en soit, les supprimer ne provoque aucun changement sur le comportement de l'application. –

4

Je peux confirmer que cela se produit uniquement sur l'appareil et non sur le simulateur. Je peux dupliquer ce comportement dans v2.2.1, 3.0 et 3.1. Si vous avez un tas de champs de texte et que vous les enchaînez en appelant: getFirstResponder dans textFieldShouldReturn comme indiqué dans l'exemple ci-dessus, et que tous les champs sont définis sur le type de clavier UIKeyboardTypeNumbersAndPunctuation, pour chaque champ SECOND, le clavier sera remplacé par UIKeyboardTypeASCIICapable.

J'ai essayé de mettre setKeyboardType: UIKeyboardTypeNumbersAndPunctuation explicitement mais cela ne fait aucune différence. Il est intéressant de noter que cela ne se produit que si vous appelez par programme getFirstResponder. Si l'utilisateur clique directement sur le champ de texte, le clavier apparaît correctement. Plus intéressant, si vous regardez la propriété keyboardType dans le débogueur, il est toujours défini sur UIKeyboardTypeNumbersAndPunctuation même si le clavier ASCII est affiché sur l'interface.

La raison pour laquelle cela se produit est parce que les claviers numériques et ASCII sont des modes différents de la même vue. L'action par défaut de la touche "suivant"/"retour" sur le clavier comprend le passage de la vue numérique à l'affichage alphabétique et c'est ce qui se passe ici.

Le correctif: renvoie NO à partir de textFieldShouldReturn pour empêcher le comportement par défaut.

Questions connexes