NSArrayController et init
Tiff
Membre
J'ai sous-classé NSArrayController.
Entre autres, j'ai réécrit la méthode init, pour donner à manger à une NSString.
Au lancement de l'appli, la NSString reste vide. J'ai mis un NSLog à l'intérieur de -init. Que dalle ! Après les dealloc qui ne sont pas appelés pour les classes MyApplicationController, voilà que les init s'y mettent. Un point commun, ces deux classes sont instanciés par I.B. Y a un rapport ?
Entre autres, j'ai réécrit la méthode init, pour donner à manger à une NSString.
Au lancement de l'appli, la NSString reste vide. J'ai mis un NSLog à l'intérieur de -init. Que dalle ! Après les dealloc qui ne sont pas appelés pour les classes MyApplicationController, voilà que les init s'y mettent. Un point commun, ces deux classes sont instanciés par I.B. Y a un rapport ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Y'a pas de rapport avec l'appel d'un déalloc de certaines classes.
Tu peux sans problèmes instancier une sous classe de NSArrayController dans IB (j'en ai fait une pour modifier le comportement de canRemove entre autre)
As tu bien déclaré sous IB que ton ArrayController était de ta classe perso. ? (tu fait lire à I.B. le header de ta classe, puis dans la fenêtre d'info, panneau custom Class, tu choisis le nom de ta classe et t'assures qu'il reste bien ainsi (il m'est arrivé que ce réglage ne soit pas validé du premier coup ??? )
Sinon, en vrac ... :
Tu utilses quoi comme initialiseur ?, initWithContent ?
As tu plus de détails sur ton implémentation de la sous classe ?
PS Que veux tu lui faire ingurgiter à ton contrôleur, ça m'intrigue ton truc
J'avais juste fait un (c'était pas un NString, mais un BOOL) mais il restait coincé à NO.
en gros, j'avais (j'ai modifié depuis) :
Je n'avais pas déclaré -(id)init; dans le fichier header.
Que dalle à quel niveau ? Passes tu dans la fonction init ?
[EDIT]
oups, Tiff tu m'as grillé.
[/EDIT]
Je n'ai pas l'impression, puisque mon NSLog n'affiche rien. Je n'ai pas essayé le debugger pour vérifier que je passais par init. Pas le temps, j'étais pressé que mon appli tourne. J'ai modifié une ligne de code (if !flag au lieu de if flag) et tout fonctionne. Mais c'est quand même bizarre cette histoire de init.
Il n'y a que 2 méthodes pour exécuter du code d'initialisation après chargement du nib :
- awakeFromNib si la classe de l'objet se conforme au protocole NSNibAwaking.
- initWithCoder qui permet de créer l'objet en mémoire à partir de son "empreinte" codée dans le nib.
.
Vu comme ça, ça parait évident 8)
Mais bon, comment fait I.B. pour initialiser les instances ?
En fait, IB ne les instancie (au sens traditionnel du terme) jamais. Les objets que manipule IB sont déjà instanciés dans la "palette". On peut dire qu'une palette dans IB est une sorte de petit nib dans lequel les objets existent sous forme "codée". Le fait de prendre un objet de la palette vers IB ne fait que copier cette "empreinte".
Certes, il y a longtemps les objets dans la palette ont été réellement instanciés, mais cela a été fait par le programmeur/concepteur de la palette !
.
Je suppose que si j'avais créé une instance de MyArrayController en codant dans MyAppController :
tout se serait passé comme prévu.
Aucune importance, awakeFromNib me convient parfaitement.
Merci à tous.
OUPSÂ :-\
Merci Bru de ta précision
J'avais oublié cet aspect :-\
En effet pour une sous Classe d'un objet standard présent dans la palette d'objet, comme un NSArray controller, le init n'est pas appelé dans le code.
Mais il y a tout de même une exception pour des custumView pour lesquelles initWithFrame est tout de même appelée.
Et aussi et surtout, une classe non dérivée d'une classe standard de la palette d'IB vera également son init appelé.
Par exemple le traditionnel ApplicationController dérivé de NSObject instancié dans le nib voit son init appelé et exécuté normalement dans le code.