On 9, Jan, 2013, at 04:26 PM, Mike Abdullah <cocoa...@mikeabdullah.net> wrote:
>
> On 8 Jan 2013, at 05:53, Martin Hewitson wrote:
>
>>
>> On Jan 7, 2013, at 08:44 PM, Mike Abdullah <cocoa...@mikeabdullah.net> wrote:
>>
>>>
>>> On 7 Jan 2013, at 16:35, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote:
>>>
>>>> Hi Francisco,
>>>>
>>>> Thanks for the feedback!
>>>>
>>>> What you suggest sounds like it might fix the problem, but I'm wondering
>>>> how best to do this. Currently I'm just calling -remove: on the tree
>>>> controller to delete the selected object(s). Of course, if I clear the
>>>> selection first, then -remove: doesn't do anything. I can grab an array of
>>>> the selected objects before clearing the selection then use
>>>> NSManagedObjectContext's -deleteObject:. So something like this:
>>>>
>>>> // get a pointer to the selected items
>>>> NSArray *items = [self selectedObjects];
>>>>
>>>> // clear selection
>>>> [self setSelectionIndexPaths:@[]];
>>>>
>>>> // now delete from the MOC
>>>> for (NSManagedObject *item in items) {
>>>> [self.managedObjectContext deleteObject:item];
>>>> [self.managedObjectContext processPendingChanges];
>>>> }
>>>>
>>>> Does that look sensible to you?
>>>
>>> Why are you calling -processPendingChanges at each iteration of the loop?
>>> Calling it yourself is rarely needed, and best done only with justification.
>>>
>>
>> I read in that thread that I referenced (I think) that it may be necessary
>> to do this to avoid/handle objects being deleted twice (if a parent and
>> child are selected, then deleted). To be honest, I'm just trying things to
>> see what works. Since this problem only occurs on 10.6.8, I think I'm
>> looking for a work-around.
>
> Hmm. In my case I go to some lengths to figure out which objects don't need
> to be deleted, because an ancestor has already been deleted. It does seem
> simpler your way.
>
> I wonder though — I don't believe there is any harm in asking Core Data to
> delete an object that's already been marked for deletion. And indeed, you
> code is doing that. The difference the -processPendingChanges call makes is
> that handling the delete rule will happen during that call, so child objects
> are already marked for deletion.
>
However, I'm still not able to get this to work on 10.6.8. Having the
-processPendingChanges call seems to make no difference.
The code I currently have in my -remove: method of the NSTreeController
subclass is
// get a pointer to the selected items
NSArray *items = [self selectedObjects];
// clear selection
[self.outlineView selectRowIndexes:[NSIndexSet indexSet]
byExtendingSelection:NO];
[self setSelectionIndexPaths:@[]];
// now from the MOC
for (NSManagedObject *item in items) {
[self removeObjectAtArrangedObjectIndexPath:[self
indexPathToObject:item]];
[self.managedObjectContext deleteObject:item];
[self.managedObjectContext processPendingChanges];
}
(-indexPathToObject: comes from a category NSTreeController_Extensions.h from
Jonathan Dann)
Despite this, I must still have a reference to a deleted object somewhere, but
I've no idea where. Could there be other reasons for getting the "CodeData
could not fulfull a fault" error?
Best wishes,
Martin
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
