Ca pourrait quand même être une solution efficace de stocker ces infos via un fichier XML ? Parce que là vu le bouzin pour essayer d'archiver un simple objet, ça me dégoutte déjà quelque peu de l'archivage, quand on le comapre avec la simplicité de l'archivage en Java.
ceci dit si tu regardes le code que je t'ai transmis ce n'est pas si compliqué ...
dans 1188150380:
Citer ce message J'ai essayé pas à pas, et je n'ai rien vu, l'exécution se stoppe bien au moment ou je déclare mon objet Data mais un step in, et je passe au return de ma méthode, l'attribut data à alors une taille de 468 Octets. Donc là je nage un peu en eaux troubles, j'y comprend pas grand chose pour débugger de façon convenable avec Xcode
Oui mais enfin, il y a bien un moment où il retourne dans encodeWithCoder pour écrire le message une seconde fois "
Encode MyDocument 0
")
Je me suis refait le déroulage pas à pas, ligne d'asm par ligne d'asm.
Après avoir frôlé la crise d'épilepsie, je comprend mal le fonctionnement du debugger, mais alors très mal, je m'explique:
J'ai un breakpoint au niveau de "NSData *data = [NSArchiver archivedDataWithRootObject: self];" Il s'arrête dessus à l'exécution, cool ça marche, je fais ensuite step in, et là j'avance ligne d'asm par ligne d'asm, pas de soucis.
Pendant ce temps, dans mon Thread 1, j'ai comme une sorte de pile d'appel des méthodes, mais en fait non. Là encore je m'explique : J'ai bien un tas de méthode appelées, dont certaines totalement obscures. Par exemple à mon premier breakpoint (création du NSData), la méthode de NSArchiver qui crée ce data est bien située en méthode numéro 0. Pas de problème.
Ensuite apparaà®t en nouveau numéro 0, une nouvelle méthode, mais cette méthode change de nom au cours du débogage, et ce sans "s'ajouter" à la pile, ce qui fait que ma méthode archivedDataWithRootObject reste à la même place qu'avant dans la list de mon thread 1.
Etrangement, certaines méthodes s'ajoutent à la pile, à un moment, ma méthode du breakpoint se trouvait même en 8ème position dans la liste. Puis ensuite elle repasse 7ème je ne sais comment.
Ensuite ça part en sucette, je clique comme un dinguo en surveillant la console et le nom des méthodes qui changent et qui ne s'ajoutent pas à la liste. J'ai ensuite le droit à des messages perturbants dans la console du genre "Unable to disassemble __i686.get_pc_thunk.bx." qulques fois, et aussi "Previous frame inner to this frame (corrupt stack?)" un grand nombre de fois.
Et là , apothéose: ma liste d'appel de méthode fond comme neige au soleil, et la méthode de mon breakpoint revient en position 0 de la liste !!!! Quelques 100ènes de lignes plus tard, une nouvelle méthode apparait, (ne s'ajoutant pas à la liste dans le thread 1) et puis là patatrac, ma méthode d'encodage est appelée une seconde fois. Bon le soucis, c'est que je n'ai plus la trace des méthodes appelées après le premier encodage (y'a eu des appels de memcopy, d'alloc, de setDictionaryValues, de encodeCStrings, de unlock spin et de lock spin et j'en passe).
Donc au moment où je rentre la seconde fois dans mon encodeWithCoder de mon controler, j'ai juste ces méthodes dans la liste:
En 0 j'ai MyDocument encodeWithCoder En 1 j'ai _encodeObject_old (déjà apparu lors du premier encodage "normal") En 2 j'ai archivedDataWithRootObject En 3 j'ai dataRepresentationOfType (qui est le breakpoint où je crée le NSData)
Donc là je me pose vraiment des questions, suis-je à ce point débile, j'ai rien compris à Xcode, pourquoi la liste des appels de méthodes est aussi étrange, pourquoi j'y comprend plus rien, et la question, faut-il être un crack de l'asm pour arriver à comprendre quelque chose au debbuger de Xcode ?
Ci joint le fichier de la console, pour les gens qui ne seront pas morts d'ennuis (pas encore !)). J'ai effectué quelques step in après la fin du second encodage. J'ai pu voir quelques instants dans les appels de méthodes des NSObject release, et des NSArchiver dealloc...
<br /> [Session started at 2007-08-26 23:54:39 +0200.] GNU gdb 6.1-20040303 (Apple version gdb-437) (Fri Jan 13 18:45:48 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. <br />Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-apple-darwin". Loading program into debugger... tty /dev/ttyp1 Program loaded. sharedlibrary apply-load-rules all run [Switching to process 2092 local thread 0xf03] Running... <br /><br />2007-08-26 23:54:42.931 Money_Organizer_0.2[2092] UpdateUI appellee 2007-08-26 23:54:42.936 Money_Organizer_0.2[2092] UpdateUI appellee 2007-08-26 23:54:42.937 Money_Organizer_0.2[2092] UpdateUI appellee Pending breakpoint 1 - ""MyDocument.m:1246" resolved Pending breakpoint 2 - ""MyDocument.m:91" resolved 2007-08-26 23:54:46.583 <br /><br />Money_Organizer_0.2[2092] La on sauvegarde Current language: auto; currently objective-c 2007-08-26 23:54:49.852 Money_Organizer_0.2[2092] ----------------------Encode MyDocument 0-------------------------------- 2007-08-26 23:54:50.283 Money_Organizer_0.2[2092] Encode User debut 2007-08-26 23:54:50.283 Money_Organizer_0.2[2092] Encode Account Debut 2007-08-26 23:54:50.283 Money_Organizer_0.2[2092] Operation encode debut 2007-08-26 23:54:50.283 Money_Organizer_0.2[2092] Operation encode Fin 2007-08-26 23:54:50.283 Money_Organizer_0.2[2092] Encode Account Fin 2007-08-26 23:54:50.283 Money_Organizer_0.2[2092] Encode User finie 2007-08-26 23:54:50.612 Money_Organizer_0.2[2092] Encode MyDocument 1 2007-08-26 23:54:51.333 Money_Organizer_0.2[2092] Encode MyDocument 2 2007-08-26 23:54:53.172 Money_Organizer_0.2[2092] Encode MyDocument 3 2007-08-26 23:54:53.380 Money_Organizer_0.2[2092] Encode MyDocument 4 2007-08-26 23:54:55.596 Money_Organizer_0.2[2092] Encode MyDocument 5 2007-08-26 23:54:56.807 Money_Organizer_0.2[2092] Encode MyDocument fini <br /><br /> Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble <br /><br />__i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable to disassemble __i686.get_pc_thunk.bx. Unable <br />to disassemble __i686.get_pc_thunk.bx. <br />Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) 2007-08-27 00:13:35.942 Money_Organizer_0.2[2092] ----------------------Encode MyDocument 0-------------------------------- 2007-08-27 00:31:07.929 Money_Organizer_0.2[2092] Encode User debut 2007-08-27 00:31:07.929 Money_Organizer_0.2[2092] Encode Account Debut 2007-08-27 00:31:07.930 Money_Organizer_0.2[2092] Operation encode debut 2007-08-27 00:31:07.930 Money_Organizer_0.2[2092] Operation encode Fin 2007-08-27 00:31:07.930 Money_Organizer_0.2[2092] Encode Account Fin 2007-08-27 00:31:07.930 Money_Organizer_0.2[2092] Encode User finie 2007-08-27 00:31:09.202 Money_Organizer_0.2[2092] Encode MyDocument 1 2007-08-27 00:31:11.066 Money_Organizer_0.2[2092] Encode MyDocument 2 2007-08-27 00:31:12.451 Money_Organizer_0.2[2092] Encode MyDocument 3 2007-08-27 00:31:13.026 Money_Organizer_0.2[2092] Encode MyDocument 4 2007-08-27 00:31:15.259 Money_Organizer_0.2[2092] Encode MyDocument 5 2007-08-27 00:31:15.986 Money_Organizer_0.2[2092] Encode MyDocument fini Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Unable to disassemble __i686.get_pc_thunk.cx. Previous frame inner to this frame (corrupt stack?) Previous frame inner to this frame (corrupt stack?) (gdb)<br /><br />
Ajout: J'ai retenté ce matin la même manip mais avec des steps overs histoire que ça aille un poil plus vite.
Au moment où je rentre une première fois dans ma méthode encodeWithCoder du controler, j'ai ça dans ma pile de méthode:
Ensuite ça part en sucette, je clique comme un dinguo en surveillant la console et le nom des méthodes qui changent et qui ne s'ajoutent pas à la liste. J'ai ensuite le droit à des messages perturbants dans la console du genre "Unable to disassemble __i686.get_pc_thunk.bx." qulques fois, et aussi "Previous frame inner to this frame (corrupt stack?)" un grand nombre de fois.
Souvent après un échec, certaines méthodes sont réexécutées. C'est peut-être ce qui t'arrive : 2 échecs successifs de l'encodage ?
'corrupt stack' ? menu Help>XCode pour voir ce qu'est cette pile
dans 1188204096:
J'ai retenté ce matin la même manip mais avec des steps overs histoire que ça aille un poil plus vite
compare avec la même manip pour l'essai que je t'ai transmis
Penses-tu à nettoyer Build > Clean All Targets pour forcer à recompiler la totalité du projet ?
Etrangement, certaines méthodes s'ajoutent à la pile, à un moment, ma méthode du breakpoint se trouvait même en 8ème position dans la liste. Puis ensuite elle repasse 7ème je ne sais comment.Â
Ensuite ça part en sucette,
belle expression : "partir en sucette" !
Repasser de 8ème position à 7eme position dans une pile d'exécution c'est un peu normal non ?
Mais si c'est là le deuxième appel de la méthode, il y a peut-être moyen de voir ce qui se passe entre 1er et 7ème ?
Autre question qu'il faut se poser l'encodage réussit-il ? et pour cela une seule solution désencoder.
Autre piste : mettre des lignes de code en commentaire, et voir le comportement.
J'ai noté l'état de la pile d'appel des méthodes (enfin ce qui y ressemble, parce que là j'y vois pas le principe, c'est une pile d'appel ou une pile de méthodes "en court" parce que pour varier de cette façon c'est louche).
Donc voilà ce que j'obtient, j'ai un premeir breakpoint au niveau de la création de mon objet NSData pour sauvegarder, et le second breakpoint dans le premier NSLog de ma méthode encodeWithCoder de mon controler.
MyDocument dataRepresentationOfType
Ensuite je rentre dans le encodeWithCoder et j'obtient
Autre question qu'il faut se poser l'encodage réussit-il ? et pour cela une seule solution désencoder.
Je veux bien essayer de désencoder de suite, mais si il encode déjà deux fois alors que dans ton exemple ça ne le fait qu'une fois, je trouve ça louche.
Ensuite, vu la tête de mon controler, je ne sais pas comment m'y prendre pour désarchiver les objets en fait.
Il faut déjà que je release mon dictionnaire, et que "j'extraie" mon objet controler encode.
<br /> id encodedControler =[[NSKeyedUnarchiver unarchiveObjectWithData:data] retain];<br />//Cela marche aussi avec un simple NSUnarchiver non ? Je n'utilise pas le Keyed dans mon //encodage<br />
Une fois mon dictionnaire release, j'ai un setter pour ce dernier, et j'ai donc juste à faire
-- Là , je le rouvre, et on voit bien qu'une initialisation d'instance a lieu avant readFromData -- -- comment cela se pourrait-il autrement puisque readFromData: est une méthode d'instance -- 2007-08-21 14:56:57.875 essaiCoderMultiple[2420] initializing 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] reading from data 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] init with coder 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] number in initWithCoder : 123 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] string in initWithCoder : toto 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] number:123 string:toto 2007-08-21 14:56:57.878 essaiCoderMultiple[2420] controller did load nib, number=123 string=toto
Donc quand on fait File>Open une instance est initialisée, en passant par init, et tout ce qui a été mis dans init est réalisé : c'est l'instance finale dont on disposera. ensuite on passe dans - (BOOL)readFromData:(NSData *)data ofType:(NSString *)aType error:(NSError**) addError La ligne de désarchivage appelle initWithCoder: , et là on obtient une nouvelle instance d'un contrôleur, copie exacte de celle qui avait été archivée. Il faut alors transmettre les info de la deuxième instance à la première.
NSUnarchiver sans key d'accord, il faut respecter l'ordre suivi dans la méthode de codage
dans 1188216227:
Il faut déjà que je release mon dictionnaire, et que "j'extraie" mon objet controler encode.
id encodedControler =[[NSKeyedUnarchiver unarchiveObjectWithData:data] retain];
Une fois mon dictionnaire release, j'ai un setter pour ce dernier, et j'ai donc juste à faire
//Setting the encoded dictionary [userDictionary setUserDictionary:[encodedControler userDictionary]];
Normalement ta fonction setUserDictionary: doit déjà gérer le release. Donc ne pas le faire deux fois.
-- Là , je le rouvre, et on voit bien qu'une initialisation d'instance a lieu avant readFromData -- -- comment cela se pourrait-il autrement puisque readFromData: est une méthode d'instance -- 2007-08-21 14:56:57.875 essaiCoderMultiple[2420] initializing 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] reading from data 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] init with coder 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] number in initWithCoder : 123 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] string in initWithCoder : toto 2007-08-21 14:56:57.876 essaiCoderMultiple[2420] number:123 string:toto 2007-08-21 14:56:57.878 essaiCoderMultiple[2420] controller did load nib, number=123 string=toto
Donc quand on fait File>Open une instance est initialisée, en passant par init, et tout ce qui a été mis dans init est réalisé : c'est l'instance finale dont on disposera. ensuite on passe dans - (BOOL)readFromData:(NSData *)data ofType:(NSString *)aType error:(NSError**) addError La ligne de désarchivage appelle initWithCoder: , et là on obtient une nouvelle instance d'un contrôleur, copie exacte de celle qui avait été archivée. Il faut alors transmettre les info de la deuxième instance à la première.
NSUnarchiver sans key d'accord, il faut respecter l'ordre suivi dans la méthode de codage
Normalement ta fonction setUserDictionary: doit déjà gérer le release. Donc ne pas le faire deux fois.
Ouaip j'avais pas fait gaffe et ça à crashé...
Merci pour ta patience Philippe !
Maintenant, j''ai l'impression que je vais devoir ajouter des accesseurs sur mon controler, dont deux pour me retourner les comptes et utilisateurs courants. L'objet retourné par le NSUnarchiver est en théorie bien une copie exacte niveau structure de mon controller, à la diffèrence près du contenu ?
Je voulais savoir si mon objet archivé était bancale ou non. J'ai donc rajouté une piote méthode appelant pour chaque objet la méthode description, et là , surprise, mon objet archivé (2 fois) est impécablement bien structuré, j'arrive donc maintenant sans soucis à sauver, charger !
Bref, je ne comprend toujours pas pourquoi il y a eu double encodage, et surtout comme mon fichier n'est pas difforme, mais bon, un mystère de plus dont j'aurais peut être la solution lors de futures applications !
En tout cas merci à vous tous, et en particulier à Philippe49 pour sa patience et son idée de tester le désencodage "à l'aveugle" !
Réponses
ceci dit si tu regardes le code que je t'ai transmis ce n'est pas si compliqué ...
Oui mais enfin, il y a bien un moment où il retourne dans encodeWithCoder pour écrire le message une seconde fois "
Encode MyDocument 0
")
qui appelle ce message et à quel moment ?
Après avoir frôlé la crise d'épilepsie, je comprend mal le fonctionnement du debugger, mais alors très mal, je m'explique:
J'ai un breakpoint au niveau de "NSData *data = [NSArchiver archivedDataWithRootObject: self];" Il s'arrête dessus à l'exécution, cool ça marche, je fais ensuite step in, et là j'avance ligne d'asm par ligne d'asm, pas de soucis.
Pendant ce temps, dans mon Thread 1, j'ai comme une sorte de pile d'appel des méthodes, mais en fait non. Là encore je m'explique : J'ai bien un tas de méthode appelées, dont certaines totalement obscures. Par exemple à mon premier breakpoint (création du NSData), la méthode de NSArchiver qui crée ce data est bien située en méthode numéro 0. Pas de problème.
Ensuite apparaà®t en nouveau numéro 0, une nouvelle méthode, mais cette méthode change de nom au cours du débogage, et ce sans "s'ajouter" à la pile, ce qui fait que ma méthode archivedDataWithRootObject reste à la même place qu'avant dans la list de mon thread 1.
Etrangement, certaines méthodes s'ajoutent à la pile, à un moment, ma méthode du breakpoint se trouvait même en 8ème position dans la liste. Puis ensuite elle repasse 7ème je ne sais comment.
Ensuite ça part en sucette, je clique comme un dinguo en surveillant la console et le nom des méthodes qui changent et qui ne s'ajoutent pas à la liste. J'ai ensuite le droit à des messages perturbants dans la console du genre "Unable to disassemble __i686.get_pc_thunk.bx." qulques fois, et aussi "Previous frame inner to this frame (corrupt stack?)" un grand nombre de fois.
Et là , apothéose: ma liste d'appel de méthode fond comme neige au soleil, et la méthode de mon breakpoint revient en position 0 de la liste !!!! Quelques 100ènes de lignes plus tard, une nouvelle méthode apparait, (ne s'ajoutant pas à la liste dans le thread 1) et puis là patatrac, ma méthode d'encodage est appelée une seconde fois. Bon le soucis, c'est que je n'ai plus la trace des méthodes appelées après le premier encodage (y'a eu des appels de memcopy, d'alloc, de setDictionaryValues, de encodeCStrings, de unlock spin et de lock spin et j'en passe).
Donc au moment où je rentre la seconde fois dans mon encodeWithCoder de mon controler, j'ai juste ces méthodes dans la liste:
En 0 j'ai MyDocument encodeWithCoder
En 1 j'ai _encodeObject_old (déjà apparu lors du premier encodage "normal")
En 2 j'ai archivedDataWithRootObject
En 3 j'ai dataRepresentationOfType (qui est le breakpoint où je crée le NSData)
Donc là je me pose vraiment des questions, suis-je à ce point débile, j'ai rien compris à Xcode, pourquoi la liste des appels de méthodes est aussi étrange, pourquoi j'y comprend plus rien, et la question, faut-il être un crack de l'asm pour arriver à comprendre quelque chose au debbuger de Xcode ?
Ci joint le fichier de la console, pour les gens qui ne seront pas morts d'ennuis (pas encore !)). J'ai effectué quelques step in après la fin du second encodage. J'ai pu voir quelques instants dans les appels de méthodes des NSObject release, et des NSArchiver dealloc...
Ajout: J'ai retenté ce matin la même manip mais avec des steps overs histoire que ça aille un poil plus vite.
Au moment où je rentre une première fois dans ma méthode encodeWithCoder du controler, j'ai ça dans ma pile de méthode:
puis ensuite après le premier encodage réussi j'ai :
Et ensuite j'ai:
Puis pour finir en beauté :
Donc pourquoi avoir ce mode pour debbuger alors que des méthodes "disparaissent" ? Pourquoi y a-t-il eu un second appel à encodeRootObject ?
Souvent après un échec, certaines méthodes sont réexécutées. C'est peut-être ce qui t'arrive : 2 échecs successifs de l'encodage ?
'corrupt stack' ? menu Help>XCode pour voir ce qu'est cette pile
compare avec la même manip pour l'essai que je t'ai transmis
Penses-tu à nettoyer Build > Clean All Targets pour forcer à recompiler la totalité du projet ?
belle expression : "partir en sucette" !
Repasser de 8ème position à 7eme position dans une pile d'exécution c'est un peu normal non ?
Mais si c'est là le deuxième appel de la méthode, il y a peut-être moyen de voir ce qui se passe entre 1er et 7ème ?
Autre question qu'il faut se poser l'encodage réussit-il ? et pour cela une seule solution désencoder.
Autre piste : mettre des lignes de code en commentaire, et voir le comportement.
Donc voilà ce que j'obtient, j'ai un premeir breakpoint au niveau de la création de mon objet NSData pour sauvegarder, et le second breakpoint dans le premier NSLog de ma méthode encodeWithCoder de mon controler.
Ensuite je rentre dans le encodeWithCoder et j'obtient
Une fois mes NSLog affiché et l'encodage fini de mon rootObject et des objets qu'il contient, j'obtient ceci
puis
puis là je passe à
et à ce moment là mon breakpoint dans encodeWithCoder est à nouveau franchi, je rerentre uen seconde fosi dedans:
Et mon second codage est effectué correctement aussi d'apres mes NSLog
puis
puis
Ensuite,
puis
et pour finir j'obtient
Je veux bien essayer de désencoder de suite, mais si il encode déjà deux fois alors que dans ton exemple ça ne le fait qu'une fois, je trouve ça louche.
Ensuite, vu la tête de mon controler, je ne sais pas comment m'y prendre pour désarchiver les objets en fait.
Il faut déjà que je release mon dictionnaire, et que "j'extraie" mon objet controler encode.
Une fois mon dictionnaire release, j'ai un setter pour ce dernier, et j'ai donc juste à faire
Est-ce la bonne façon de le faire ?
-- comment cela se pourrait-il autrement puisque readFromData: est une méthode d'instance --
2007-08-21 14:56:57.875 essaiCoderMultiple[2420] initializing
2007-08-21 14:56:57.876 essaiCoderMultiple[2420] reading from data
2007-08-21 14:56:57.876 essaiCoderMultiple[2420] init with coder
2007-08-21 14:56:57.876 essaiCoderMultiple[2420] number in initWithCoder : 123
2007-08-21 14:56:57.876 essaiCoderMultiple[2420] string in initWithCoder : toto
2007-08-21 14:56:57.876 essaiCoderMultiple[2420] number:123 string:toto
2007-08-21 14:56:57.878 essaiCoderMultiple[2420] controller did load nib, number=123 string=toto
Donc quand on fait File>Open
une instance est initialisée, en passant par init, et tout ce qui a été mis dans init est réalisé : c'est l'instance finale dont on disposera.
ensuite on passe dans - (BOOL)readFromData:(NSData *)data ofType:(NSString *)aType error:(NSError**) addError
La ligne de désarchivage appelle initWithCoder: , et là on obtient une nouvelle instance d'un contrôleur, copie exacte de celle qui avait été archivée. Il faut alors transmettre les info de la deuxième instance à la première.
NSUnarchiver sans key d'accord, il faut respecter l'ordre suivi dans la méthode de codage
Normalement ta fonction setUserDictionary: doit déjà gérer le release. Donc ne pas le faire deux fois.
Ouaip j'avais pas fait gaffe et ça à crashé...
Merci pour ta patience Philippe !
Maintenant, j''ai l'impression que je vais devoir ajouter des accesseurs sur mon controler, dont deux pour me retourner les comptes et utilisateurs courants. L'objet retourné par le NSUnarchiver est en théorie bien une copie exacte niveau structure de mon controller, à la diffèrence près du contenu ?
C'est une copie exacte .. de ce que tu as copié via encodeWithCoder
Bref, je ne comprend toujours pas pourquoi il y a eu double encodage, et surtout comme mon fichier n'est pas difforme, mais bon, un mystère de plus dont j'aurais peut être la solution lors de futures applications !
En tout cas merci à vous tous, et en particulier à Philippe49 pour sa patience et son idée de tester le désencodage "à l'aveugle" !