On 10, Jan, 2013, at 06:25 PM, Peter <magn...@web.de> wrote:
>
> Am 10.01.2013 um 18:06 schrieb Martin Hewitson:
>
>> And I forgot to mention: the persistent store seems to get saved since when
>> I restart the app (it's unusable after the CoreData error) the removed
>> entities are not present. Curiouser and curiouser.
>>
>> Martin
>>
>>
>>
>> On 10, Jan, 2013, at 06:05 PM, Martin Hewitson <martin.hewit...@aei.mpg.de>
>> wrote:
>>
>>>
>>> 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.
>
> What about the undo manager - if you are using undo?
I think the MOC handles its own undo manager, right? At least I'm not doing
handling it myself and I can undo the deletions. But surely the MOC will take
care of deletion and undo properly, won't it?
Martin
>
>>> 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/magnard%40web.de
>>
>> This email sent to magn...@web.de
_______________________________________________
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
