Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de
NSWindowController (WC) en File's Owner, une fenêtre (W) avec une
NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de
la table.
DS a une variable d'instance qui est liée à WC.
Si j'ai bien compris la doc "Document-Based Applications -> Window
Closing Behavior", dans ce cas WC (et donc W) ne sera pas
automatiquement relaché si je ferme W car WC est "retained" plus d'une
fois (par le NSDocument et par DS).
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc
mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Schmurtz
Frédéric Testuz wrote:
Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de NSWindowController (WC) en File's Owner, une fenêtre (W) avec une NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de la table.
DS a une variable d'instance qui est liée à WC.
Le lien est fait avec Interface Builder je suppose. Donc il retient WC une fois de plus pour cette variable.
C'est peut-être de là que vient le problème : WC retient DS et DS retient WC. Ainsi même si tu supprimes touts les autres références (en les relâchant bien sûr) vers ces deux objets, ils resteront tous les deux en mémoire, perdu dans le vide, se retenant l'un à l'autre (normalement ils devraient tomber, mais en fait non ;) ).
Si j'ai bien compris la doc "Document-Based Applications -> Window Closing Behavior", dans ce cas WC (et donc W) ne sera pas automatiquement relaché si je ferme W car WC est "retained" plus d'une fois (par le NSDocument et par DS).
exactement.
Dans la doc d'Apple, c'est marqué je ne sais plus où qu'il ne faut retenir un object fils, mais jamais retenir son père, histoire d'éviter ce problème.
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Tu peux aussi rajouter dans la méthode awakeFromNib du DS :
[_laVariableContenantWC release];
afin de conserver cette variable, mais sans retenir l'objet (ce qui est fait pas défaut)
-- Schmurtz
Frédéric Testuz wrote:
Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de
NSWindowController (WC) en File's Owner, une fenêtre (W) avec une
NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de
la table.
DS a une variable d'instance qui est liée à WC.
Le lien est fait avec Interface Builder je suppose. Donc il retient WC
une fois de plus pour cette variable.
C'est peut-être de là que vient le problème : WC retient DS et DS
retient WC. Ainsi même si tu supprimes touts les autres références (en
les relâchant bien sûr) vers ces deux objets, ils resteront tous les
deux en mémoire, perdu dans le vide, se retenant l'un à l'autre
(normalement ils devraient tomber, mais en fait non ;) ).
Si j'ai bien compris la doc "Document-Based Applications -> Window
Closing Behavior", dans ce cas WC (et donc W) ne sera pas
automatiquement relaché si je ferme W car WC est "retained" plus d'une
fois (par le NSDocument et par DS).
exactement.
Dans la doc d'Apple, c'est marqué je ne sais plus où qu'il ne faut
retenir un object fils, mais jamais retenir son père, histoire d'éviter
ce problème.
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc
mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Tu peux aussi rajouter dans la méthode awakeFromNib du DS :
[_laVariableContenantWC release];
afin de conserver cette variable, mais sans retenir l'objet (ce qui est
fait pas défaut)
Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de NSWindowController (WC) en File's Owner, une fenêtre (W) avec une NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de la table.
DS a une variable d'instance qui est liée à WC.
Le lien est fait avec Interface Builder je suppose. Donc il retient WC une fois de plus pour cette variable.
C'est peut-être de là que vient le problème : WC retient DS et DS retient WC. Ainsi même si tu supprimes touts les autres références (en les relâchant bien sûr) vers ces deux objets, ils resteront tous les deux en mémoire, perdu dans le vide, se retenant l'un à l'autre (normalement ils devraient tomber, mais en fait non ;) ).
Si j'ai bien compris la doc "Document-Based Applications -> Window Closing Behavior", dans ce cas WC (et donc W) ne sera pas automatiquement relaché si je ferme W car WC est "retained" plus d'une fois (par le NSDocument et par DS).
exactement.
Dans la doc d'Apple, c'est marqué je ne sais plus où qu'il ne faut retenir un object fils, mais jamais retenir son père, histoire d'éviter ce problème.
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Tu peux aussi rajouter dans la méthode awakeFromNib du DS :
[_laVariableContenantWC release];
afin de conserver cette variable, mais sans retenir l'objet (ce qui est fait pas défaut)
-- Schmurtz
testuz73
Schmurtz wrote:
Frédéric Testuz wrote:
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Tu peux aussi rajouter dans la méthode awakeFromNib du DS :
[_laVariableContenantWC release];
afin de conserver cette variable, mais sans retenir l'objet (ce qui est fait pas défaut)
Merci pour tout.
Et question guère importante : c'est une convention utile le _ devant des variables.
-- Frédéric Testuz <mailto:
Schmurtz <moi@ici.com> wrote:
Frédéric Testuz wrote:
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc
mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Tu peux aussi rajouter dans la méthode awakeFromNib du DS :
[_laVariableContenantWC release];
afin de conserver cette variable, mais sans retenir l'objet (ce qui est
fait pas défaut)
Merci pour tout.
Et question guère importante : c'est une convention utile le _ devant
des variables.
J'avais mis cette variable pour accéder plus vite à WC, je ferais donc mieux d'utiliser les méthodes d'accès de NSControl et NSWindow ?
Tu peux aussi rajouter dans la méthode awakeFromNib du DS :
[_laVariableContenantWC release];
afin de conserver cette variable, mais sans retenir l'objet (ce qui est fait pas défaut)
Merci pour tout.
Et question guère importante : c'est une convention utile le _ devant des variables.
-- Frédéric Testuz <mailto:
testuz73
Schmurtz wrote:
Frédéric Testuz wrote:
Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de NSWindowController (WC) en File's Owner, une fenêtre (W) avec une NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de la table.
DS a une variable d'instance qui est liée à WC.
Le lien est fait avec Interface Builder je suppose. Donc il retient WC une fois de plus pour cette variable.
C'est peut-être de là que vient le problème : WC retient DS et DS retient WC. Ainsi même si tu supprimes touts les autres références (en les relâchant bien sûr) vers ces deux objets, ils resteront tous les deux en mémoire, perdu dans le vide, se retenant l'un à l'autre (normalement ils devraient tomber, mais en fait non ;) ).
Je viens de controller avec ObjectAlloc. Je n'ai encore rien modifier, donc j'ai toujours les références en boucle, et bien quand je ferme la fenêtre le count d'objet WC passe à 0. Cocoa a l'air donc de très bien se débrouiller avec les références circulaires créées par IB en tout cas.
-- Frédéric Testuz <mailto:
Schmurtz <moi@ici.com> wrote:
Frédéric Testuz wrote:
Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de
NSWindowController (WC) en File's Owner, une fenêtre (W) avec une
NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de
la table.
DS a une variable d'instance qui est liée à WC.
Le lien est fait avec Interface Builder je suppose. Donc il retient WC
une fois de plus pour cette variable.
C'est peut-être de là que vient le problème : WC retient DS et DS
retient WC. Ainsi même si tu supprimes touts les autres références (en
les relâchant bien sûr) vers ces deux objets, ils resteront tous les
deux en mémoire, perdu dans le vide, se retenant l'un à l'autre
(normalement ils devraient tomber, mais en fait non ;) ).
Je viens de controller avec ObjectAlloc. Je n'ai encore rien modifier,
donc j'ai toujours les références en boucle, et bien quand je ferme la
fenêtre le count d'objet WC passe à 0.
Cocoa a l'air donc de très bien se débrouiller avec les références
circulaires créées par IB en tout cas.
Ma question est celle-ci. Dans un fichier .nib j'ai une sous-classe de NSWindowController (WC) en File's Owner, une fenêtre (W) avec une NSTableView (TV) et une instance d'un objet pour le dataSource (DS) de la table.
DS a une variable d'instance qui est liée à WC.
Le lien est fait avec Interface Builder je suppose. Donc il retient WC une fois de plus pour cette variable.
C'est peut-être de là que vient le problème : WC retient DS et DS retient WC. Ainsi même si tu supprimes touts les autres références (en les relâchant bien sûr) vers ces deux objets, ils resteront tous les deux en mémoire, perdu dans le vide, se retenant l'un à l'autre (normalement ils devraient tomber, mais en fait non ;) ).
Je viens de controller avec ObjectAlloc. Je n'ai encore rien modifier, donc j'ai toujours les références en boucle, et bien quand je ferme la fenêtre le count d'objet WC passe à 0. Cocoa a l'air donc de très bien se débrouiller avec les références circulaires créées par IB en tout cas.
-- Frédéric Testuz <mailto:
Schmurtz
Frédéric Testuz wrote:
Merci pour tout.
C'est normal. Et en plus pour une fois que j'arrive à répondre à une question. Je connais plein de chose, mais il y a tellement de bibliothèques et fonctionnalités que je
Et question guère importante : c'est une convention utile le _ devant des variables.
Absolument pas. C'est juste une convention pour différencier les membres d'instance et les variables locales. Ça permet aussi de pas se triturer les méninges pour utiliser des noms différent dans une méthode du genre :
C'est normal. Et en plus pour une fois que j'arrive à répondre à une
question. Je connais plein de chose, mais il y a tellement de
bibliothèques et fonctionnalités que je
Et question guère importante : c'est une convention utile le _ devant
des variables.
Absolument pas. C'est juste une convention pour différencier les membres
d'instance et les variables locales. Ça permet aussi de pas se triturer
les méninges pour utiliser des noms différent dans une méthode du genre :
C'est normal. Et en plus pour une fois que j'arrive à répondre à une question. Je connais plein de chose, mais il y a tellement de bibliothèques et fonctionnalités que je
Et question guère importante : c'est une convention utile le _ devant des variables.
Absolument pas. C'est juste une convention pour différencier les membres d'instance et les variables locales. Ça permet aussi de pas se triturer les méninges pour utiliser des noms différent dans une méthode du genre :
