Ok, je suis surpris que personne ne rapportés ci plus tôt, mais il ya un bug dans le chapitre 9 d'application. Si vous appuyez-and-hold l'intérieur d'un des champs de texte pour faire apparaître la loupe, qui fonctionne, mais si vous essayez ensuite de déplacer le curseur après la loupe apparaît, pas de chance.
Ma conjecture quant à ce qui se passe est que parce que UITableView est une sous-classe de UIScrollView, il intercepte l'événement glisser assez longtemps au mess avec le code UITextField de glisser la manipulation.
Après le problème a été signalé, j'ai fait une petite recherche. Il s'avère qu'il ya une solution de contournement à ce comportement affiché à Stack Overflow par Stephen Darlington .
Je suis mise à jour du code source du projet avec la solution de contournement, mais cela peut prendre quelques jours pour obtenir la nouvelle version affichée. J'ai travaillé à travers les projets de livres essayons de les amener à courir sous le SDK 3.0, mais qui ont besoin de revenir en arrière toutes les modifications 3,0 spécifiques avant que je puisse afficher le code de sorte que je ne risque pas involontairement violer la NDA. En attendant, voici comment vous pouvez corriger le comportement de l'application de navigation à partir du livre. Dans PresidentDetailController.m, Ajoutez la méthode suivante:
Puis, en viewDidLoad, ajoutez la ligne de code suivante:
Cette approche de base devrait travailler n'importe où vous avez des champs de texte ou les vues texte à l'intérieur d'une table. Cela ne fonctionnera pas si vous avez besoin le mode d'édition sur la table, cependant, si vous avez deux champs éditables et utilisez le mode édition, vous êtes probablement violer le HIG de toute façon et devraient envisager une refonte.
Ma conjecture quant à ce qui se passe est que parce que UITableView est une sous-classe de UIScrollView, il intercepte l'événement glisser assez longtemps au mess avec le code UITextField de glisser la manipulation.
Après le problème a été signalé, j'ai fait une petite recherche. Il s'avère qu'il ya une solution de contournement à ce comportement affiché à Stack Overflow par Stephen Darlington .
Je suis mise à jour du code source du projet avec la solution de contournement, mais cela peut prendre quelques jours pour obtenir la nouvelle version affichée. J'ai travaillé à travers les projets de livres essayons de les amener à courir sous le SDK 3.0, mais qui ont besoin de revenir en arrière toutes les modifications 3,0 spécifiques avant que je puisse afficher le code de sorte que je ne risque pas involontairement violer la NDA. En attendant, voici comment vous pouvez corriger le comportement de l'application de navigation à partir du livre. Dans PresidentDetailController.m, Ajoutez la méthode suivante:
- (BOOL)tableView:(UITableView *)tableView canEditRowAtIndexPath:(NSIndexPath *)indexPath
{
return NO;
}Puis, en viewDidLoad, ajoutez la ligne de code suivante:
self.editing = YES;Cette approche de base devrait travailler n'importe où vous avez des champs de texte ou les vues texte à l'intérieur d'une table. Cela ne fonctionnera pas si vous avez besoin le mode d'édition sur la table, cependant, si vous avez deux champs éditables et utilisez le mode édition, vous êtes probablement violer le HIG de toute façon et devraient envisager une refonte.
Aucun commentaire:
Enregistrer un commentaire