On Fri, Jul 29, 2011 at 12:39 AM, Charles Srstka <[email protected]> wrote: > Actually, on further thought, this can’t be true, can it? Plenty of methods > built right into the frameworks create objects on the fly — call > valueForKey: to retrieve a property that’s declared as an NSInteger, and > you’ll get an NSNumber object that was created to wrap it. Send valueForKey: > to an array, and you get a newly-created array containing the results of > getting that property from each object in the array. Both of these times, > you’re not going to have the same pointer on subsequent calls, and these > work fine, so pointer discrepancies can’t be the cause of his problem.
Yes, this works, but I believe the problem is that KVO is getting two different pointer values for the same key at a time where it thinks the value should be constant. Of course, I don't have access to the KVO internals, but I've seen this happen if you call -myProperty from within a KVO prior notification for that property, and it returns a different value than when KVO started notifying you of the property change. KVO maintains a stack of properties currently being notified. It also reads the current value of the property in -willChangeValueForKey: for the purposes of sending prior notifications and for filling in the NSKeyValueChangeOldKey. My gut is telling me that someone's calling -valueForKey: in response to a KVO notification, and KVO is noticing that the pointer value it's returning does not match the pointer value it has in its internal "I'm notifying people about this change" table. Of course, my gut could be very wrong. --Kyle Sluder _______________________________________________ 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]
