UIWindow endDisablingInterfaceAutorotationanimated d'erreur s'affiche dans la console lorsque le clavier est rejeté de manière interactive à partir de collectionView dans iOS9 seulement

J'obtiens cette erreur étrange dans iOS9 seulement:

[UIWindow endDisablingInterfaceAutorotationAnimated:] called on UITextEffectsWindow: ...without matching
-beginDisablingInterfaceAutorotation. Ignoring.

chaque fois que j'ai fermer le clavier de manière interactive en les faisant glisser vers le bas à partir de l'intérieur de mon collectionView. Je n'ai pas l'erreur en rejetant le clavier avec un robinet d'un geste ou en appuyant sur entrée. C'est très frustrant. Même si je ne suis pas d'observer n'importe quel clavier notifications j'obtiens toujours cette erreur sur cette interactive clavier licenciement. Je me demande si quelqu'un d'autre a rencontré cette erreur et a trouvé une solution. J'ai un inputAccessoryView composé d'un textView monté sur le clavier.

Je le vois ainsi. Peut-être la peine de mentionner sur iOS 9 seulement. L'exécution même application sur iOS 8 n'a pas d'imprimer quoi que ce soit dans la console.
Merci pour votre commentaire. Vous avez raison sur elle ne se produit que dans iOS9. J'ai modifié la question afin de refléter cela.
C'est clairement un système de bug
Toujours présent sur iOS 10.
Je suis présent sur iOS 11 lorsque le balayage sur la tableView d'un UISearchResultsController... L'application se bloque après avoir appuyé sur une cellule après que l'erreur qui s'est passé

InformationsquelleAutor alionthego | 2015-10-11

26

J'ai eu le même problème sur iOS9, mais avec une tableView. J'ai mis en place cette avec self.tableView.keyboardDismissMode = .Interactive et il a travaillé pour moi.
```
//Dismiss keyboard when scrolling
func scrollViewWillBeginDragging(scrollView: UIScrollView) {
    textView.resignFirstResponder()
}
```
- J'ai eu le même problème quand il y avait inputAccessoryView sur mon domaine. Ils se cachaient en 2 étapes: clavier et après que inputAccessoryView. Cela m'a aidé. Ils se cachent en même temps maintenant.
- cela fonctionne pour mon avec mon collectionView ainsi. merci beaucoup.
- Depuis que j'ai accepté, j'ai remarqué à l'aide de cette suggestion il y a des occasions où le inputAccessoryView en réalité disparaît donc je vais continuer à chercher une solution.
- il fonctionne pour moi, mais j'ai changé textView.resignFirstResponder() pour view.endEditing(true)parce que j'ai 5 textFields. Espérons qu'il pourrait aider quelqu'un d'autre
- J'ai remarqué à l'aide de cette suggestion que de Rejeter de manière Interactive devient une sorte de Rejeter sur un Glisser (qui a te même problème d'erreur de toute façon), cela empêche l'utilisateur de changer l'esprit et annuler l'opération pour fermer le clavier (et des pertes de la sélection) en les faisant glisser.
- MAIS non .effet interactif après ce code, et que votre code est très cool.
InformationsquelleAutor vandit
6

Choses à Vérifier

Il semble que plusieurs autres de SORTE que les utilisateurs ont eu des expériences similaires dans une variété de conditions. Découvrez ce fil. Depuis, il pourrait y avoir beaucoup de choses qui se passent à l'origine de ce problème, vous pouvez consulter le fil fourni pour voir si vous pouvez trouver un correspondant de cas d'utilisation. Il est difficile de savoir comment vous êtes rejetant le clavier, mais vous voudrez peut-être appeler quelque chose comme ceci à partir d'une méthode ou comme un geste de reconnaissance (plutôt qu'un licenciement à partir d'un objet spécifique):

UIApplication.sharedApplication().sendAction("resignFirstResponder", to: nil, from: nil, forEvent: nil)

Le fil fourni, la nature de la question dans la plupart des cas de double appel lors de la présentation ou le rejet de la vue. J'ai aussi vu des questions où j'ai un storyboard segue connecté (ou, dans certains cas, il a été enlevé, mais le xml était encore dans la table de montage en mode code) et d'un code basé sur des enchaînements (performSegueWithIdentifier...) pour la même animation (ce qui provoque un affichage à l'/rejeter des appels).

Je regardais le journal pour voir ce que les appels sont enregistrés juste avant l'erreur, puis faire une recherche dans le journal pour voir si il y a une redondance d'appel. De nouveau, il pourrait également être une redondance dans les comportements/animations/mise en page sur le storyboard et les appels faits dans le code.

Mise à JOUR

Les commentaires de l'OP, m'a rappelé que, dans certains cas, en particulier celles impliquant des appels lors de présentations/licenciements, j'ai vu des cas où la seule façon de réussir à avoir un développeur de la fonction de travail est l'envelopper dans un dispatch_async appel. Il y a certains systèmes critiques des appels qui ne semblent pas bien fonctionner si le code du développeur est introduit au cours de la même image.

Un exemple concret est cet appel qui est à l'intérieur de willMoveToWindow. Dans ce cas j'ai un weakSelf référence à la vue et il vous suffit de vérifier la newWindow pour la valeur nil (indique que la vue est rejetée) avant d'appeler mon code.

Donc, dans cet exemple, si l'on supprime l'envoi appel, puis le code du développeur serait la cause de la totalité de l'app crash. Je suppose que le système de transition d'appels (liées à la transposition vers/à partir de la fenêtre) peut être une source de conflit avec n'importe quel développeur de demandes à l'époque.
```
 dispatch_async(dispatch_get_main_queue(), { () -> Void in

     //the saved flag is true only when user hits the done button
     if !(weakSelf!.saved) {
         weakSelf?.completeNotes(nil)
     }

 })
```
- salut. merci pour votre post. je crois que le double appel est en raison de la inputAccessoryView. il semble avec une inputAccessoryView monté le keyboardDidChange de notification est envoyé deux fois à chaque fois que le clavier est affiché ou masqué. comme si tout d'abord le clavier est rejeté, et puis le inputAccessoryView est mis dans l'affichage. je pense que c'est la cause de cela et d'autres problèmes, mais pas sûr de la façon de la contourner si j'ai envie de continuer à l'aide de la inputAccessoryView.
- Je pensais que l'erreur a été liée à l'utilisation interactive de licenciement, mais dans mon cas, j'ai suivi cette erreur vers le bas pour un appel manuel de resignFirstResponder à l'affichage de texte. L'envoi de la resignFirstResponder action le répondeur de l'arbre n'empêche pas l'erreur, mais au moins mon entrée accessoire de vue est correctement supprimé de l'écran. Je me demandais si il n'a rien à voir avec le fait que mon entrée accessoire de vue conserve une (forte) de référence à la l'affichage de texte... va enquêter et de faire rapport de toute nouvelle information.
- Cela devrait être la réponse choisie. En particulier, la mise à jour développeur sur les actions qui ont besoin d'être dans un bloc async (ou de nos jours un reporter bloquer) pendant les événements du système est parfaitement logique et a résolu mon problème.
InformationsquelleAutor Tommie C.
2

J'ai rencontré ce problème et il bousille mon point de vue. C'est de cette façon-je le résoudre.

J'ai eu un viewController présentés sur les textFieldShouldBeginEditing. Dans le viewController, un textField a été mis à becomeFirstResponder dans viewDidLoad.

La solution pour moi est de déplacer le becomeFirstResponder à viewDidAppear.
- J'ai eu le message d'erreur même si j'ai fait le becomeFirstResponder appel dans viewDidAppear.
InformationsquelleAutor okysabeni

Vous devez vous connecter pour publier un commentaire.

Choses à Vérifier