As he stated, -remove: does work, but its result is deferred. On 15 May 2010, at 03:56, Tony Romano wrote:
> Thanks Quincey. > > removeObjectAtArrangedObjectIndexPath works but remove: still does not. It > should remove the object, if there is a bug then I will file a bug report. > anyone have ideas as to why remove: may not be working. I hate to find > another way and drop a possible issue/bug. Thanks. > > -Tony > > > On May 14, 2010, at 4:55 PM, Quincey Morris wrote: > >> On May 14, 2010, at 15:39, Tony Romano wrote: >> >>> I have a NSOutlineView bound to a NSTreeController in class mode(i.e. each >>> NSTreeNode represents my Node object). Everything up to now is working >>> fine. I am trying to remove a single node in the outline view by calling >>> [outlineView remove:self] as a test. The documents are pretty simple and >>> they state that the remove: method removes the selected item, simple >>> enough. I've put some test code around the remove. The test code is >>> looking at the selected node Before the remove then looking at the selected >>> node again(assuming the controller picked a new selection). The before and >>> after are the same which is also reflected in the UI. I verified this in >>> the debugger. Here's the snippet. >>> >>> ... >>> NSArray * selectedObjects = [outlineController selectedObjects]; >>> >>> // Only selecting one node for the test, it should be at index 0. >>> Node * node = [selectedObjects objectAtIndex:0]; >>> NSIndexPath * paths = [outlineController selectionIndexPath]; >>> >>> [outlineController remove:self]; >>> selectedObjects = [outlineController selectedObjects]; >>> >>> node = [selectedObjects objectAtIndex:0]; >>> >>> paths = [outlineController selectionIndexPath]; >>> >>> >>> The canRemove binding which is hooked up to the menu item, is working(Menu >>> Item is enabled). Is there some setting I am completely overlooking. >>> Searching has come up empty handed. >> >> You read the documentation for 'remove:' but apparently not all of it: >> >>> Special Considerations >>> Beginning with Mac OS X v10.4 the result of this method is deferred until >>> the next iteration of the runloop so that the error presentation mechanism >>> can provide feedback as a sheet. >> >> So of course it hasn't been done when you check immediately after invoking >> the 'remove:' action. If you want it to happen immediately, you would need >> to use 'removeObjectAtArrangedObjectIndexPath:' instead. >> >> But ... >> >> Depending on where this code is, it may be a lousy idea to do the removal >> via the tree controller anyway. You're always better off changing the data >> model directly (the thing that is providing the tree controller with >> content). >> >> If I say this often enough, one day someone might listen. >> >> >> >> _______________________________________________ >> >> 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/tonyrom%40hotmail.com >> >> This email sent to tony...@hotmail.com >> > > -Tony > > _______________________________________________ > > 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/cocoadev%40mikeabdullah.net > > This email sent to cocoa...@mikeabdullah.net _______________________________________________ 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 arch...@mail-archive.com
