›

[GC] Fenêtre qui se "finalize"

chrixtianchrixtian Membre
17:02 modifié dans API AppKit #1
Bonjour à  tous :)

J'ai activé le GC only dans un projet qui est composé comme suit:
+ un NIB avec une fenêtre principale (celle qui s'ouvre lors du lancement de l'appli)
+ un autre NIB avec une fenêtre qui s'ouvre lors d'un click sur un menu de la fenêtre principale.

Voilà  ce qui se passe. La fenêtre principale s'ouvre, je m'amuse à  cliquant ci et là , etc. Puis je clique sur le menu qui charge le second NIB (via NSBundle) et affiche la deuxième fenêtre. Et là , il se passe un truc de bizarre: ma première fenêtre se "finalize" et disparait :(

Quelqu'un pourrait-il m'expliquer pourquoi ? Est-ce l'appel à  la méthode de chargement du NIB via NSBundle qui marque la première fenêtre comme "collectable" par le GC ?

Je suis vraiment curieux de comprendre le phénomère.
Merci  o:)


Réponses

  • Philippe49Philippe49 Membre
    17:02 modifié #2
    Chargement incorrect de la seconde fenêtre ?

    Si on était pas sous GC, je te dirais qu'il manque un retain quelque part.
  • chrixtianchrixtian Membre
    mai 2008 modifié #3
    dans 1211912757:

    Chargement incorrect de la seconde fenêtre ?

    Si on était pas sous GC, je te dirais qu'il manque un retain quelque part.


    Le problème doit bien venir du chargement du second Nib. Car la première fenêtre est détruite seulement après le chargement de celui-ci.
    Par contre, le NIB est chargé d'une manière tout ce qu'il y a de plus "classique":
    <br />- (IBAction) addSavingsAccount:(id) sender<br />{<br />	NSLog( @&quot;Add a new savings account&quot; );<br />	CSAddingAccountController *accountCntrl = [[ CSAddingAccountController alloc] init];<br />	<br />	if (![NSBundle loadNibNamed:@&quot;AddAccount&quot; owner: accountCntrl])<br />&nbsp; &nbsp; {<br />&nbsp; &nbsp; &nbsp; &nbsp; NSLog(@&quot;Warning! Could not load AddAccount file.&#092;n&quot;);<br />		return;<br />&nbsp; &nbsp; }<br />	<br />	[accountCntrl display];<br />}<br /><br />


    Et le code de ma fonction display est:
    <br />- (void) display<br />{<br />	[winform makeKeyAndOrderFront: self];<br />}<br />


    EDIT: Par contre, quand je supprime l'appel à  la méthode display, ma fenêtre principale reste mais pas la seconde qui se fait détruire dès qu'elle s'affiche :(


  • Philippe49Philippe49 Membre
    17:02 modifié #4
    Ton accountController est créé localement, donc à  la sortie de la fonction que devient-il ?


     
  • Philippe49Philippe49 Membre
    17:02 modifié #5
    -(void) display est une méthode déjà  utilisée par pas mal de classes.
    Si ta classe hérite d'une classe définissant cette méthode, il risque d'y avoir confusion.

    Change le nom de cette méthode ...
  • chrixtianchrixtian Membre
    17:02 modifié #6
    dans 1211913416:

    Ton accountController est créé localement, donc à  la sortie de la fonction que devient-il ?


    Il doit être détruit... Mais pourquoi est-ce la première fenêtre qui saute ?

  • chrixtianchrixtian Membre
    17:02 modifié #7
    dans 1211913562:

    -(void) display est une méthode déjà  utilisée par pas mal de classes.
    Si ta classe hérite d'une classe définissant cette méthode, il risque d'y avoir confusion.

    Change le nom de cette méthode ...


    display_ploumploum ne fait meilleure recette :/

  • Philippe49Philippe49 Membre
    mai 2008 modifié #8
    dans 1211914025:

    display_ploumploum ne fait meilleure recette :/

    C'est dommage c'était rigolo  :)

    As-tu essayé en déclarant une variable accountCntrl dont la durée de vie serait supérieure à  celle de ta fonction ? lors de suppression intempestive de données, les réactions des programmes sont parfois inattendues. On peut imaginer par exemple que le Window Manager ayant une liste de fenêtres à  gérer s'emmêle les pinceaux si un windowcontroller disparaà®t.
  • chrixtianchrixtian Membre
    17:02 modifié #9
    dans 1211914478:

    As-tu essayé en déclarant une variable accountCntrl dont la durée de vie serait supérieure à  celle de ta fonction ? lors de suppression intempestive de données, les réactions des programmes sont parfois inattendues. On peut imaginer par exemple que le Window Manager ayant une liste de fenêtres à  gérer s'emmêle les pinceaux si un windowcontroller disparaà®t.


    J'ai mis la variable comme propriété de la classe. Mais sans succès :(

  • chrixtianchrixtian Membre
    17:02 modifié #10
    Bon... voilà  la suite de l'aventure: tant que je ne fais pas de makeKeyAndOrderFront sur la seconde fenêtre, no problemo.
    Euh... que pourrait faire cette méthode pour entraà®ner cet effet de bord ?  ???

  • Philippe49Philippe49 Membre
    17:02 modifié #11
    Voilà  un essai simple qui marche avec GC-Only et makeKeyAndOrderFront
  • chrixtianchrixtian Membre
    mai 2008 modifié #12
    dans 1211920556:

    Voilà  un essai simple qui marche avec GC-Only et makeKeyAndOrderFront


    Merci :)

    Je regarde ton projet... mais je me dis: comment fait-il pour charger le second Nib ? ???

    [EDIT]
    J'ai trouvé. C'est avec le initWithWindowNibName :)
    Par contre, mon objet à  la base était juste un NSObject. Je vais tenter de modifier mon code pour changer la classe :)

  • chrixtianchrixtian Membre
    17:02 modifié #13
    dans 1211920556:

    Voilà  un essai simple qui marche avec GC-Only et makeKeyAndOrderFront


    Je ne comprends rien. J'ai fait comme dans ton projet (du moins, je crois) mais ça ne marche pas.

    Je joints mon projet. Pourrais tu me dire si tu vois la "coquille" ?  :o
    Merci  o:)

  • Philippe49Philippe49 Membre
    mai 2008 modifié #14
    Le phénomène ne se produit pas en supprimant le Test IB 1.nib et en mettant le tout dans MainMenu.nib.
    L'instance de Test_IB_1_AppDelegate qui se trouve dans MainMenu.nib doit exister.

    Bizarre également que ton groupe Products ne contienne pas un .app
  • chrixtianchrixtian Membre
    17:02 modifié #15
    dans 1211949574:

    Le phénomène ne se produit pas en supprimant le Test IB 1.nib et en mettant le tout dans MainMenu.nib.
    L'instance de Test_IB_1_AppDelegate qui se trouve dans MainMenu.nib doit exister.

    Bizarre également que ton groupe Products ne contienne pas un .app


    C'est fourbe  :-\\
    Quand j'ai commencé le dév, je voulais appréhender la nouvelle version d'IB. J'ai donc commencé par créer les écrans via IB et j'ai ensuite décidé de faire le projet xcode pour les intégrer. J'avais donc modifier la propriété Target afin qu'elle utilise le nib Test IB 1 et non mainmenu (j'ai suivi le guide qu'apple fourni pour faire cette opération).

    J'ai l'impression que cela pose quelque soucis de faire IB -> XCode.
    Mais c'est vraiment galère car comment faire si tu veux demander à  d'autres personnes de concevoir les écrans sans qu'elles aient le projet ? Sauf si cela pose problème seulement avec le mainmenu.nib  ???
  • Philippe49Philippe49 Membre
    17:02 modifié #16
    Je n'ai pas testé, mais c'est peut-être tout simplement qu'il suffit de déplacer Test_IB_1_AppDelegate vers ton nib importé.

    Dans ce genre de situation je supprime le MainMenu.nib, et j'importe le nouveau nib ... que j'appelle MainMenu.nib et cela ne pose aucun problème.
  • Philippe49Philippe49 Membre
    17:02 modifié #17
    dans 1211969329:

    Je n'ai pas testé, mais c'est peut-être tout simplement qu'il suffit de déplacer Test_IB_1_AppDelegate vers ton nib importé.

    Oui, après test, c'est cela.
  • chrixtianchrixtian Membre
    17:02 modifié #18
    dans 1211978618:

    dans 1211969329:

    Je n'ai pas testé, mais c'est peut-être tout simplement qu'il suffit de déplacer Test_IB_1_AppDelegate vers ton nib importé.

    Oui, après test, c'est cela.

    Euh... j'ai pas de mac sous la main. Mais, c'est quoi le Test_IB_1_AppDelegate ?
  • Philippe49Philippe49 Membre
    17:02 modifié #19
    A ce que je crois tu as fait un projet "Core Data Application"
    Ce projet installe automatiquement un fichier xxxxxxxxAppDelegate dont une instance est préinstallée dans le fichier MainMenu.nib. Je connais mal CoreData, mais d'après le nom et le contenu de ce fichier, ce dernier n'est rien d'autre qu'un contrôleur de l'application. Autant dire que le supprimer, ça craint  :brule:  :fouf):
  • chrixtianchrixtian Membre
    17:02 modifié #20
    Merci pour tout Philippe  o:)  
Connectez-vous ou Inscrivez-vous pour répondre.