La connexion Cocoa liée à NSToolbarItem empêche-t-elle la désinitialisation?

Vous essayez de définir le segment sélectionné d'un NSToolbarItem qui est un NSSegmentedControl via liaison de liaison à une propriété (optionSegment). Sous-classer le contrôleur de fenêtre en tant que telLa connexion Cocoa liée à NSToolbarItem empêche-t-elle la désinitialisation?

class MyWindow: NSWindowController { 
    dynamic var optionSegment: Int = 0 

    override func windowDidLoad() { 
     super.windowDidLoad() 
    } 
}

En variante, mettre la propriété optionSegment dans la sous-classe NSDocument et lier à cela. Chaque travail. Le problème est qu'avec cette liaison, ou apparemment aucune liaison à NSToolbarItem, aucun de mes objets (vues, contrôleurs de vue, document, etc.) ne désinitialisera. Avec une liaison, ils ne le font pas. Retirez la reliure et ils le font.

Des idées pourquoi tout cela pourrait-il être ainsi? Suggestions? Assez perplexe.

Merci!

Source

2016-04-20 JKaz

Vous voulez dire deallocate? [J'ai trouvé que je devais démonter explicitement les liaisons pour que le contrôleur de fenêtre se désengage] (http://stackoverflow.com/questions/23944436/should-i-need-to-unbind-cocoa-bindings-in-dealloc -of-windowcontroller). Cela ne devrait pas être le cas, mais ça l'est. À ce stade, je reviendrai probablement et m'assurerai que tous mes IBOutlets sont 'faibles 'pour s'assurer que les seules références' strong' sont dans la hiérarchie de la vue. Vous * pourriez * avoir un IBOutlet fort qui empêche le dealloc d'onduler la hiérarchie de vue, bien que je ne sois pas sûr que cela ait de l'importance seulement avec la liaison. – stevesliva

C'est Swift, donc je fais référence à la méthode deinit des classes. Je vais regarder dans le lien que vous avez fourni et voir ce qui est possible dans Swift pour résoudre ce problème. Merci! – JKaz

En l'absence de liaison, la méthode deinit {} du contrôleur de fenêtre est appelée en premier et se répercute sur le contrôleur de vue, le document, les vues, les données, etc. Chaque objet reçoit sa définition dans l'ordre logique. Avec même une seule propriété liée à un seul NSToolbarItem, le deinit du contrôleur de fenêtre n'est pas appelé, et aucun des autres ne l'est non plus, donc le code n'atteint pas le seul endroit où je serais capable d'abattre le fixations. Il n'y a pas d'IBOutlets forts qui, comme vous le soulignez, seraient aussi un facteur sans liaison. – JKaz

Comme Willeke l'a suggéré, toolbarItem.view était le chemin du succès. Je dois dire que la hiérarchie des objets n'est pas toujours claire pour moi, mais .view semblait la seule possibilité que j'ai regardé la barre d'outils crochets du jour au lendemain, et la suggestion de Willeke l'a confirmé. La documentation Apple sur la reliure mentionne qu'il est de notre responsabilité de délier certains objets, alors qu'elle en délie les autres. Voici le code que j'ai mis dans ma sous-classe NSDocument pour tout déconnecter, et le contrôleur de vue désinitialise maintenant.

func windowWillClose(notification: NSNotification) { 
    let wcs = self.windowControllers 
    if wcs.count == 0 { return } 
    let wc = wcs[0] 
    let toolbar = wc.window?.toolbar 
    if toolbar != nil { 
     let items = toolbar!.items 
     for item in items { 
      let v = item.view 
      if v != nil { 
       // print(v?.className) 
       let objects = v!.exposedBindings 
       for object in objects { 
        // print(object + " " + item.label + " " + v!.className) 
        v!.unbind(object) 
       } 
      } 
     } 
    } 
}

Ce fut l'un des concepts les plus confus que j'ai rencontré - tant de pièces mobiles - et grâce à Willeke & stevesliva pour la boîte de dialogue qui serpentait à une solution.

De NSObject (NSKeyValueBindingCreation):

Toutes les fixations standards sur les objets AppKit (vues, cellules, colonnes de table, contrôleurs) délie leurs liaisons automatiquement quand ils sont désalloué, mais si vous créez la valeur clé bindings pour d'autres objets , vous devez vous assurer que vous supprimez ces liaisons avant deallocation (les objets observés ont de faibles références à leurs observateurs , donc les contrôleurs/objets du modèle peuvent continuer à référencer et la messagerie les objets qui leur étaient liés).

Source

2016-04-21 16:53:29 JKaz

Bon travail de creuser ce blockquote déconnecté. On dirait que si vous liez un contrôle à autre chose qu'à un contrôleur, tous les paris sont désactivés pour que le désengagement fonctionne automagiquement. – stevesliva

La connexion Cocoa liée à NSToolbarItem empêche-t-elle la désinitialisation?

Répondre

Questions connexes