J'essaie de la sous-classe UIAUPLICATION pour attraper tous les événements tactiles, il est utilisé pour voir si l'utilisateur est afk ou non. Quoi qu'il en soit, cela fonctionne parfaitement pour la première fois que vous lancez l'application. Si vous le mettez en arrière-plan et ouvrez-le à nouveau 2 fois, il se bloque. Je n'ai aucune idée de ce qui cause cela. Je reçois EXEC_BAD_Access sur [Super SendEvent: événement];
My Sous-classe MyUI: P>
int main(int argc, char *argv[])
{
NSString* appClass = @"MyUI";
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, appClass, nil);
[pool release];
return retVal;
}
5 Réponses :
Ne comprend pas ce que "afk" signifie.
Une autre approche pourrait être de créer un reconnaissance de geste personnalisé. Ils (reconnaissants de gestes) sont censés filtrer par des événements tactiles avant qu'ils ne soient transférés dans le cadre du traitement de l'événement Normal Touches.
Afk signifie loin du clavier. Dans un autre mot, je vérifie si l'utilisateur utilise toujours l'iPad / iPhone ou si l'utilisateur est absent.
OK, la classe UIAPPlication transforme les événements à l'UIWindow. Et si au lieu de sous-classement uiapplication, vous sous-classez UiWindow et collez votre traitement dans sa méthode SendEvent: (uievente *). J'ai essayé cela et ajouté un NSLog () / [Super SendEvent: événement] à la mienne et vu des événements qui sortent.
Aussi, pour la façon dont vous le faites, si vous avez simplement le "[Super SendEvent: événement]; // <- Exec_bad_access" ligne et éloignez-vous des trucs que vous avez ajoutés ci-dessous, est-ce qu'il crit? Si oui, alors quelque chose est gâché parce que vous ne devriez pas vraiment changer les choses avec cela. Je serais de retour qui change et voyez si c'est toujours écrasé alors.
Pour obtenir une raison exacte de EXEC_BAD_Access Utilisez NszombieEnabled dans votre application. Ce lien vous guidera pour l'utiliser. http://iosdevelopertaps.com/debugging/tracking-down-down exc_bad_access-erreurs-with-nszombieenabled.html
Pouvez-vous s'il vous plaît expliquer où vous avez eu une fuite? J'ai le même problème
Exactement; Si cette réponse vous a aidé à trouver le problème, veuillez mettre à jour votre question ou ajouter un commentaire expliquant la cause de la cause / comment vous l'avez résolue. Cela pourrait aider les autres personnes!
Y a-t-il une raison pour laquelle la méthode Super Class est appelée en premier? Si vous interceptez, vous devriez l'appeler en dernier.
Cela pourrait être votre problème. Je remplace également Sendevent pour intercepter tous les événements à ma demande et sans problème.
Si vous appelez la super méthode d'abord, il le transmettra à tous les répondeurs d'habitants qui pourraient éventuellement manger votre événement entraînant l'exécuteur exécutant. En outre, comme Davidneiss suggère d'éliminer les lignes sous le Super Call. Si vous recevez toujours le mauvais signal d'accès, il est probable une autre vue ou un contrôleur en bas de la ligne le causant. Vous devrez empiler la trace pour savoir où il se trouve.
Juste pour la simplicité, je mettrais le @ "myui" directement dans l'appel UIAPPlicationMain.
La chaîne est probablement votre problème. C'est en dehors du De plus, le nom @ "myUI" indique sur un contrôleur d'affichage, pas une classe d'appdelegate. Regarde dans ça. NsautoreleePool , et c'est tout simplement pas fait.
[Super SendEvent: événement]; // <- Exec_bad_access
signifie que l'erreur est dans votre classe.
pour le bloc de test Vous obtiendrez toujours cette erreur. À tout moment si vous obtenez une erreur en remplaçant SendEvent
Essayez de bloquer toute la méthode de remplacement et de vérifier toujours que vous obtenez cette erreur ou non spécialement pour cette ligne Cela vous aidera à comprendre le bon problème. [Super SendEvent: événement]; . J'avais aussi bloqué avec cette erreur et je n'avais compris aucune erreur dans cette méthode. Erreur a été trouvée dans ApplicationDidDfinishLaunching . Gardez toujours votre code au sein d'essayer la méthode de capture
Ajout d'un point d'arrêt d'exception générique (qui met en cache toutes les exceptions en XCode) est une solution bien meilleure que d'envelopper votre code dans l'essai attrayez.
Pouvez-vous ajouter une trace de pile? J'utilise la même approche dans mon application pour suivre chaque événement tactile et ça marche bien.