Hello Corbin.
ok, so I read your blog post, its great, I love it.
I followed what you said there with my application, when the app crashes I see
the address, I search for it and I see only one result, so I click the arrow
next to the address to check the history and I have this situation.
first I have a Malloc, responsible CoreData, responsible caller [NSSQLCore
_prepareResultsFromResultSet:usingFetchPlan:withMatchingRows:],
and right after that event I have the Zombie. responsible CoreData, Responsible
caller [NSManageObject objectDictionaryWithValuesForKeys:]
So when I click the zombie and check the extended view, the last line of code
that I have control over is the accessor for the userDictionary attribute in
the User ManagedObject, which has these lines of code.
-(NSDictionary *)userDictionary{
return [self dictionaryWithValuesForKeys:[NSArray
arrayWithObjects:@"firstName",@"lastName",@"avatar",@"title",nil]];
}
I also have this line of code in the User ManageDObject
+(NSSet *)keyPathsForValuesAffectingUserDictionary{
return [NSSet
setWithObjects:@"firstName",@"lastName",@"avatar",@"title",nil];
}
dunno if this affects in somehow.. I stilld on't get what for is it, i think
its to track changes of the object for those keys.
So, if I have comming back to the initial quesiton, if I have no ivars in the
cusotm NSCell, Im just drawing the values in the values like this
-(void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView{
NSDictionary * cellValues = [self objectValue];
NSString * firstName = [cellValues valueForKey:@"firstName"];
NSString * lastName = [cellValues valueForKey:@"lastName"];
....
...
}
then what am I doing wrong?
thx.
Gustavo
On Feb 17, 2010, at 11:31 PM, Corbin Dunn wrote:
>
> On Feb 17, 2010, at 2:14 PM, Gustavo Pizano wrote:
>
>>
>> On Feb 17, 2010, at 11:03 PM, Jim Correia wrote:
>>
>>> On Feb 17, 2010, at 4:41 PM, Gustavo Pizano wrote:
>>>
>>>> Maybe I misunderstood I must conform NSCopying protocol also even when
>>>> using core data?
>>>
>>> If you have an NSCell subclass which adds iVars, you must implement
>>> -copyWithZone: to do correct memory management.
>>>
>>> Your -copyWithZone: needs to work correctly within the bounds of the object
>>> ownership rules.
>>>
>>> If you have an object iVar which shouldn’t be copied, but is still an owned
>>> reference, then you can (and must) retain it instead in the copy.
>>>
>>> (You should do this for all cells with iVars, not just ones with object
>>> iVars, so that your subclass will behave correctly in the future even if
>>> NSCell doesn’t implement its behavior using NSCopyObject.)
>>>
>>> - Jim
>>
>> Hello Jim
>> HMM digging more into the problem.. definitely it seems because Im not
>> copying properly the NSManagedObject Paul Robinson says in one old post:
>>
>> "The short answer is that you need to override the setObjectValue: method
>> (which tries to copy your uncopyable NSManagedObject) in your custom NSCell
>> to convert your NSManagedObject into an NSValue (which is copyable)."
>>
>>
>> And taking what you said, so if my User ManagedObject returns me the
>> NSDictionary with the key-value of its attributes, then in the cell I must
>> set it as an ivar within the method setObjectValue, then implement the
>> copyWithZone and return the copy of it isn't it? right now I don't have any
>> ivar in my custom cell.. sooo . := :S.
>
> I think Jim and I are leading you off track; if your cell has no extra ivars,
> then you don't have to worry about the cell implementing copyWithZone:.
>
> I still think you should read my blog posting and see why the crash happens
> with zombies on.
>
> corbin
_______________________________________________
Cocoa-dev mailing list ([email protected])
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]
