Re: Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very*  
wrong. For one thing, 'insertObject' is (according to the  
documentation) for controller subclasses to use to customize their  
own behavior, not for other things to use to insert objects.  
Normally, you don't want to mess with trying to change  
arrangedObjects directly.




On the contrary, insertObject:atArrangedObjectIndex: is provided  
precisely so that you can add an object at a particular location.
See Bookmarks at  for an example.



Very interesting reading, thanks a lot. This will keep me busy I guess.

Regards
Markus
--
__
Markus Spoettl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[mmalc crawford]

On Apr 11, 2008, at 12:10 AM, Quincey Morris wrote:
For another thing, assuming you're approaching this using MVC design  
principles, this code gets things exactly backwards -- when setting  
up your data model, you don't make changes to the controller and  
expect them to be reflected in the model -- you make changes in the  
model and let them be reflected (via the controller) in the view.



This is at best misleading.
It is perfectly reasonable to make changes to the controller an expect  
them to be propagated to the underlying model.  You do this. for  
example, when invoking an array controller's add: or insert: method.


It's not clear what the relevance is of mentioning the MVC pattern  
here -- controllers do manipulate the model object graph.



Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very*  
wrong. For one thing, 'insertObject' is (according to the  
documentation) for controller subclasses to use to customize their  
own behavior, not for other things to use to insert objects.  
Normally, you don't want to mess with trying to change  
arrangedObjects directly.




On the contrary, insertObject:atArrangedObjectIndex: is provided  
precisely so that you can add an object at a particular location.
See Bookmarks at  for an example.


mmalc

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

On Apr 11, 2008, at 12:10 AM, Quincey Morris wrote:
Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very*  
wrong. For one thing, 'insertObject' is (according to the  
documentation) for controller subclasses to use to customize their  
own behavior, not for other things to use to insert objects.  
Normally, you don't want to mess with trying to change  
arrangedObjects directly.


For another thing, assuming you're approaching this using MVC design  
principles, this code gets things exactly backwards -- when setting  
up your data model, you don't make changes to the controller and  
expect them to be reflected in the model -- you make changes in the  
model and let them be reflected (via the controller) in the view.


Again assuming there's nothing very strange intended here, all you  
need to do is update treeContent in a KVO-compliant way, which (in  
the case of arrays) is:


	[[myDocument mutableArrayValueForKey:@"treeContent"]  
addObject:rootnode];


(or some variant such as insertObject...) and the tree controller  
will see the change and update the user interface.


There are also other ways to change treeController in a KVO- 
compliant way, but mutableArrayValueForKey seems the most direct in  
this case.



I got it to work. What you say makes a lot of sense now, thanks very  
much for helping me understand what really was wrong with the code. Of  
course it solved the leaking problem and works really nicely. I'm new  
to the concept that a node (or any object) will change its class to  
something else once added to the KVO structure appropriately and  
"learns" new things as it's added. It's quite cool.


Thanks again!

Regards
Markus

PS: Question remains why Apple doesn't know how to really do this -  
it's the sample project I got this code from.

--
__
Markus Spoettl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

On Apr 11, 2008, at 12:10 AM, Quincey Morris wrote:
Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very*  
wrong. For one thing, 'insertObject' is (according to the  
documentation) for controller subclasses to use to customize their  
own behavior, not for other things to use to insert objects.  
Normally, you don't want to mess with trying to change  
arrangedObjects directly.


For another thing, assuming you're approaching this using MVC design  
principles, this code gets things exactly backwards -- when setting  
up your data model, you don't make changes to the controller and  
expect them to be reflected in the model -- you make changes in the  
model and let them be reflected (via the controller) in the view.


Again assuming there's nothing very strange intended here, all you  
need to do is update treeContent in a KVO-compliant way, which (in  
the case of arrays) is:


	[[myDocument mutableArrayValueForKey:@"treeContent"]  
addObject:rootnode];


(or some variant such as insertObject...) and the tree controller  
will see the change and update the user interface.


There are also other ways to change treeController in a KVO- 
compliant way, but mutableArrayValueForKey seems the most direct in  
this case.



OK, thanks for the input, I'll try make sense of all this later today.  
The NSTreeController/structure code was copied/used from the Apple- 
supplied sample project SourceView


  http://developer.apple.com/samplecode/SourceView

and I thought they would know what they're doing. I'm not sure what to  
think now. Anyway, thanks again!


Regards
Markus
--
__
Markus Spoettl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Quincey Morris]

On Apr 10, 2008, at 23:01, Markus Spoettl wrote:

Yes that must be it. I'm not sure how I manage to do that, though.  
Basically what I do is this:


 NSIndexPath *location = [NSIndexPath indexPathWithIndex: 
[treeContent count]];


 TreeNode *rootnode = [[TreeNode alloc] init];
 ... set treenode properties ...

 [treeController insertObject:rootnode  
atArrangedObjectIndexPath:location];


 ... do something that involves rootnode like adding sub-nodes ...

 [rootnode release]

The treeController will retain rootnode at the time insertObject is  
called and also adds rootnode to treeContent. Again, at least that's  
what I thought. There is no other place in the code that deals with  
or releases/retains TreeNode objects.


Well, without knowing the details of what you're doing, it's  
impossible to be certain, but this code certainly looks *very* wrong.  
For one thing, 'insertObject' is (according to the documentation) for  
controller subclasses to use to customize their own behavior, not for  
other things to use to insert objects. Normally, you don't want to  
mess with trying to change arrangedObjects directly.


For another thing, assuming you're approaching this using MVC design  
principles, this code gets things exactly backwards -- when setting up  
your data model, you don't make changes to the controller and expect  
them to be reflected in the model -- you make changes in the model and  
let them be reflected (via the controller) in the view.


Again assuming there's nothing very strange intended here, all you  
need to do is update treeContent in a KVO-compliant way, which (in the  
case of arrays) is:


	[[myDocument mutableArrayValueForKey:@"treeContent"]  
addObject:rootnode];


(or some variant such as insertObject...) and the tree controller will  
see the change and update the user interface.


There are also other ways to change treeController in a KVO-compliant  
way, but mutableArrayValueForKey seems the most direct in this case.


P.S. Your retain/release stuff is fine as is.


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

On Apr 10, 2008, at 8:48 PM, Quincey Morris wrote:
Perhaps the controller is not getting released when it should. Do  
you have an instance variable for the controller too? If so, how is  
that retained/released? You could probably avoid the error by  
sending a "setContent:nil" message to the controller in the  
document's dealloc, but that would just be papering over the problem.


Agreed. The NSTreeController does have an outlet on the NSDocument  
class but it's not retained/released there as it's managed through the  
nib management (at least that's what I thought).


Or perhaps the objects in treeContent are all getting overreleased.  
That could cause the error messages you're seeing.



Yes that must be it. I'm not sure how I manage to do that, though.  
Basically what I do is this:


  NSIndexPath *location = [NSIndexPath indexPathWithIndex: 
[treeContent count]];


  TreeNode *rootnode = [[TreeNode alloc] init];
  ... set treenode properties ...

  [treeController insertObject:rootnode  
atArrangedObjectIndexPath:location];


  ... do something that involves rootnode like adding sub-nodes ...

  [rootnode release]

The treeController will retain rootnode at the time insertObject is  
called and also adds rootnode to treeContent. Again, at least that's  
what I thought. There is no other place in the code that deals with or  
releases/retains TreeNode objects.


Regards
Markus
--
__
Markus Spoettl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Quincey Morris]

On Apr 10, 2008, at 19:46, Markus Spoettl wrote:

I thought I don't have to retain treeContent since I automatically  
do that with alloc-init, right?


That's right.

Perhaps the controller is not getting released when it should. Do you  
have an instance variable for the controller too? If so, how is that  
retained/released? You could probably avoid the error by sending a  
"setContent:nil" message to the controller in the document's dealloc,  
but that would just be papering over the problem.


Or perhaps the objects in treeContent are all getting overreleased.  
That could cause the error messages you're seeing.



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

The first thing to check is how you are initializing the treeContent  
variable. What method are you using to create it, and are you  
retaining it?


OK, this is what I do:

- (id)init
{
self = [super init];
if (self) {
treeContent = [[NSMutableArray alloc] init];
}
return self;
}

- (void)dealloc
{
[treeContent release];
[super dealloc];
}

I thought I don't have to retain treeContent since I automatically do  
that with alloc-init, right?


When treeContent is released, I assume it automatically releases all  
TreeNode objects in it and that's what is reported in the log entry to  
be unexpected. I get as many warnings as root node entries in  
treeContent but none for child objects further down the hierarchy.


Markus
--
__
Markus Spoettl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Quincey Morris]

On Apr 10, 2008, at 18:52, Markus Spoettl wrote:

So the question remains, how to tell NSTreeController to release all  
ties to the node hierarchy so it can be cleaned up?


The first thing to check is how you are initializing the treeContent  
variable. What method are you using to create it, and are you  
retaining it?



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Re: Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

On Apr 10, 2008, at 6:07 PM, Markus Spoettl wrote:
If I interpret this correctly I'm removing my tree content from  
under the NSTreeController while it's still using it. If found that  
when I add


   [treeContent removeAllObjects];



Small correction this (calling removeAllObject) doesn't remove the  
problem, I don't know why it appear that way at first. Overall it  
makes more sense that way because I guess that it would be called  
automatically when disposed of.


So the question remains, how to tell NSTreeController to release all  
ties to the node hierarchy so it can be cleaned up?


Regards
Markus
--
__
Markus Spoettl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Question about NSTreeController/NSOutlineView instance cleanup

[Markus Spoettl]

Hi,

  I have a simple test application (modeled after the SourceView  
sample) which is a NSDocument based application. The NSDocument  
derived class contains a root NSMutableArray which serves as the  
content for an NSOutlineView which is attached to the content through  
binding.


@interface MyDocument : NSDocument {
[...]
NSMutableArray *treeContent;
[...]
}

treeContent is never accessed directly (except for initialization and  
deallocation), it's managed by a NSTreeController instance that is  
part of the document's nib file.


The problem now is i -(void)dealloc: for MyDocument:

- (void)dealloc
{
[treeContent release];

   [super dealloc];
}

This causes the following debugger log:

--
2008-04-10 17:50:02.641 AppDocTest[7852:813] An instance 0x160ad0 of  
class TreeNode is being deallocated while key value observers are  
still registered with it. Observation info is being leaked, and may  
even become mistakenly attached to some other object. Set a breakpoint  
on NSKVODeallocateBreak to stop here in the debugger. Here's the  
current observation info:

 (
children, Options:  Context: 0xa00be78c,  
Property: 0x160530>
Options:  Context: 0xa00be78c, Property:  
0x14f140>

)
--

If I interpret this correctly I'm removing my tree content from under  
the NSTreeController while it's still using it. If found that when I add


[treeContent removeAllObjects];

before [treeContent release] this log entry goes away, but I'm not at  
all convinced this is the right procedure. So what is? How do I tell  
the NSTreeController to remove all ties to my nodes because we are  
shutting down?


I'm very new to Cocoa so there might be something I did wrong in the  
setup. I very closely followed the SourceView sample though which  
works with a NSWindowController instead of NSDocument and does not  
produce this log entry) Thanks for any pointers.


Regards
Markus
--
__
Markus Spoettl
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]