validité pour les timer

@importer

Bonjour, aprés avoir arrété mes timer avec la méthode invalidate, je voudrais tester qu'ils sont bien arrétés en faisant :

if(([timer1 isValid] == NO)&&([timer2 isValid] == NO)){[...]}

mais j''ai une erreur :

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFType isValid]: unrecognized

(je ne comprend pas le message d'ailleur)
Est ce que quelqu'un connait une méthode (la condition plutôt) pour vérifier que mes 2 timer sont bien arrétés?
Merci

apocaalypso

Et si tu vires les parenthèses :

if([timer1 isValid] == NO && [timer2 isValid] == NO)

Tu peux aussi faire comme ça :

if(![timer1 isValid] && ![timer2 isValid])

@importer

salut apocaalypso, malheureusement j'avais déja testé tes proposition avant de poster, et j'ai le même problème avec. Le message d'erreur est [NSCFSet isValid]: unrecognized selector sent to instance 0x529be0 en utilisant la méthode avec ![]
C'est vraiment bizarre parce que avant de tester si mes timers sont arrétés je teste justement pour chacun des 2, lequel est en route (les 2 ne tournent pas en même temps), et je les fait s'arréter au bout de 3 et 5 secondes (preuve à  l'appuis dans mon log)

Ceetix

On dirai que tu testes des timers qui n'existent pas .

@importer

Bah à  moins qu'ils soient détruits quand on  utilise la méthode invalidate, mais à  ce moment là  où est l'intéret de isValid? Là  vraiment je voit pas, j'ai beau chercher...

Philippe49

Lorsqu'on crée un timer par une des méthodes scheduledTimer... , il est ajouté à  la runloop . La runloop fait un retain sur le timer , et le timer fait un retain sur sa target. Lorsque l'on fait [theTimer invalidate] la runloop fait un release sur le timer qui se trouve en position d'être désalloué à  la fin de la current runloop. Ton timer est donc en situation d'être détruits lors de ton test isValid.

Si tu veux vérifier que ton timer disparaà®t, deux solutions :

• Sous-classer NSTimer et mettre un message dans le dealloc.

@interface myTimer : NSTimer;<br />{ }<br />@end<br />//===================<br />@implementation MyTimer<br />-(void) dealloc {<br />      NSLog(@&quot;deallocing %@&quot;,self);<br />      [super dealloc];<br />}<br />//===================<br /><br />// appel<br />      [MyTimer scheduledTimer.....];<br /><br />

2) Faire un retain à  la création du timer, et utiliser isValid. Ne pas oublier le release.

<br />// appel<br />      [[NSTimer scheduledTimer.....] retain];<br />

@importer

Grand merci Philippe, vraiment, chapeau bas!

Ceetix

Le sage a parlé : amen

Philippe49

Merci, foule 

AliGator

L'autre solution si tu ne veux pas faire un retain (en plus de celui implicite fait par la RunLoop quand tu fais scheduledTimerXXX....) et un release, tu peux aussi penser à  mettre à  nil ton timer dès qu'il n'est plus valide.

Ainsi au lieu de faire un "retain" après le "scheduledTimerXXX..." et un release à  la fin, tu peux faire un "myTimer = nil" juste après ton [myTimer invalidate], puisque tu n'as pas de raison de garder trace d'un Timer invalide (d'autant que si tu ne fais pas de retain comme expliqué plus haut du coup plus personne le le retient pas même la RunLoop donc il se détruit tout seul).
Du coup si tu le remet à  nil juste après lui avoir envoyé la commande invalidate, tu n'as plus qu'à  tester si ton Timer est nil (donc [tt]if (myTimer)[/tt] et non pas [tt]if ([myTimer isValid])[/tt])

Nebuchad34

Tout à  fait d'accord avec AliGator, j'allais poster pour le dire.
Je fait toujours comme ça c'est très pratique. Il me semble même que c'est une astuce donnée dans le Aaron Hillegass. Me tromp-je ? 

Philippe49

Tu ne te trompjes point . 

@importer

Je suis d'accord aussi, j'y ai pensé en rentrant du taf.
Merci à  tous et à  trés bientôt dans un autre sujet que je vais créer, euh... disons, tout de suite.