Comment organiser les objets et l'interface graphique

wisky

Bonjour à  tous,

J'ai un petit problème à  vous soumettre. Avant de me lancer à  corps perdu dans la programmation d'un gros projet, j'aimerai savoir comment faire ceci:

mon appli dispose d'une fenêtre centrale avec une liste de projet ouvert. A côté de cette liste les différent élément du projet s'affiche.
Un projet comporte plusieurs sous objet qu'il est le seul à  utiliser. Chacun de ces objet à  besoin d'une interface graphique (élaborer sous IB).

Ce que je veut, c'est pouvoir ouvrir plusieurs fenêtres de gestion de projet avec plusieurs projets dedans. comment le faire, je par sur une appli document-based?

Et autre question, comment faire pour spécifier à  un objet (obj-c) le chargement de son interface graphique avec lequel il est lié?
Et comment ça ce gère en mémoire? il y a autant d'interface graphique chargé que d'objet?

Eddy58

Je pense que le mieux est en effet une application multi-documents, ensuite tu charges les fichiers nib selon les besoins.

wisky

Je pense que c'est la meilleur solution. J'ai réaliser un petit progamme de test en créant mes propres objets.
Cela donne : App : Controlleur Fenêtre : Controleur Projet : Controlleur Module
Le problème vient que mes objects "controlleur fenêtre" sont stocker dans un NSMutableArray et que je le parcours pour différente raison. Tout plante quand un objet Controlleur Fenêtre est détruit et que je reparcour le tableau car il y a un vide à  l'emplacement de l'objet détruit.

AliGator

dans 1150720780:

Je pense que c'est la meilleur solution. J'ai réaliser un petit progamme de test en créant mes propres objets.
Cela donne : App : Controlleur Fenêtre : Controleur Projet : Controlleur Module
Le problème vient que mes objects "controlleur fenêtre" sont stocker dans un NSMutableArray et que je le parcours pour différente raison. Tout plante quand un objet Controlleur Fenêtre est détruit et que je reparcour le tableau car il y a un vide à  l'emplacement de l'objet détruit.

Heu tu dois t'y prendre bizarrement parce que :

• Un objet rajouté dans une collection (telle que NSMutableArray) est automatiquement retenu (retain) par ladite collection, et relâché (release) quand tu l'en supprimes.
  Ainsi au moment où tu ajoutes ton contrôlleur à  ton NSMutableArray, il est retenu par ce dernier. Tu peux alors le "relâcher" dans ton programme principal puisque le mutableArray garde une "laisse" dessus pour le retenir.
  
  Et quand tu supprimes un élément du NSMutableArray, ça ne laisse jamais de "place vide" :
  • soit tu as bien fait un removeObject sur ton NSMutableArray et le contrôleur est alors retiré du mutablearray, le reste du tableau étant décallé pour combler la "place vide", (et là  c'est bon, pas de pb)
    
  • soit tu release ton contrôleur (une fois de trop) alors qu'il est encore dans le mutableArray, du coup il est supprimé de la mémoire alors que tu ne l'as pas supprimé du mutablearray (parce que tu as fait un release de trop), et le pointeur qui est stocké dans le mutablearray n'est plus valide. (donc problème voire crash, il faut enlever ton release de trop)
    
  
  
  
• Mais sinon il y a aussi une raison plausible à  ton plantage : c'est si jamais tu supprimes un élément de ton tableau pendant que tu le parcourres. La doc Apple dit bien qu'il ne faut jamais supprimer un élément d'un conteneur quand tu le parcourres avec par exemple des enumerator...
  

  http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSEnumerator_Class/Reference/Reference.html a écrit:

  Note: It is not safe to modify a mutable collection while enumerating through it. Some enumerators may currently allow enumeration of a collection that is modified, but this behavior is not guaranteed to be supported in the future.

  
  Pour palier à  ça tu peux par exemple mettre de côté dans un mutablearray temporaire les éléments à  supprimer, ainsi tu mémorise ceux qu'ils faudra supprimer, et à  la fin de ton énumération, tu effectues la procédure de suppression des éléments mémorisés, mais pas pendant le parcours.
  

wisky

Pour laisser la place vide, ou plutôt pour que le pointeur stocker dans le NSMutableArray soit invalide il suffi que l'objet pointé se détruise. C'est mon cas. Le contrôleur contient une fenêtre, lorsque celle ci est fermer le contrôleur se détruit.
J'ai réglé le problème en demandant à  l'objet parent de supprimer l'objet en cours de destruction. Le problème ne se pose plus maintenant. Mes objets communique entre eux dans les deux sens.

AliGator

Ca sent la conception bizarrement foutue quand même ton truc lool

Oui du coup en effet il faut que, si tu prévois de détruire ton contrôlleur, que tu en informes ton tableau, c'est le mieux.

Ceci dit c'est pas normal que ça fasse ça : je veux dire normalement si ton contrôlleur est utilisé à  la fois par ta fenêtre et dans ton MutableArray, chacun de ces 2 trucs ont dû mettre un retain sur ton contrôlleur : à  la fois ton mutablearray et ta fenêtre devraient retenir ton contrôlleur.

Du coup quand ta fenêtre se ferme, le contrôlleur ne devrait pas ête détruit, mais juste recevoir un release de la part de la fenêtre. son retainCount redescendrait à  1, car il serait toujours retenu par le mutableArray. Certes ton contrôlleur risque de ne plus te servir à  grand chose en effet, si la fenêtre associée est fermée, mais en tout cas le pointeur du contrôlleur est toujours valide dans le MutableArray.

Donc à  mon avis c'est pas ton pointeur vers ton contrôlleur qui était invalide, c'est que ce dernier faisait appel à  ta fenêtre par exemple, et elle par contre était détruite donc son pointeur dans le contrôlleur invalide.

Ca ne change pas l'idée qu'il faut que tu informes ton mutableArray en effet quand la fenêtre est détruite, tel que tu l'as fait, mais l'explication est donc autre part.
Ou alors tu as fait un release de trop.

wisky

c'est moi qui demande au controleur de s'auto détruire quand la fenêtre est fermé
enfin bon c'est pas superbement fait...
Ca marche et je comprend ma démarche alors qu'avec le document based je comprend rien... (enfin presque) :P