On 13 Aug 2014, at 23:41, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote:
> On Aug 13, 2014, at 14:53 , Jonathan Mitchell <jonat...@mugginsoft.com> wrote: > >> At one point i need to invoke a manual KVO notification like so: >> >> [submission willChangeValueForKey:@“status”]; >> [submission didChangeValueForKey:@“status”]; >> >> This raises like so: >> >> Terminating app due to uncaught exception >> 'NSInternalInconsistencyException', reason: 'Cannot update for observer >> <NSKeyValueObservance 0x608000ac21b0> for the key path "status.name" from >> <Submission 0x6080003aa800>, most likely because the value for the key >> "status" has changed without an appropriate KVO notification being sent. >> Check the KVO-compliance of the Submission class.’ > > This is one of those infuriating errors that is hard to make sense of. Try > thinking about it literally. > > Because you’re observing the “status.name” path from ‘submission’, the > observer is *also* observing the “name” path from ‘submission.status’**. In > your scenario, the originally observed ‘status’ instance (call it X) is no > longer the current ‘status’ instance at willChange time (it’s now Y, say), > and in general it might not be the same as that at didChange time (Z, say). > Even if Y == Z, there’s been a non-KVO-compliant change in ‘status’ prior to > the notification being sent. > > Now, we do this quite often, without problems, but I’d suggest that’s only in > cases where the “temporarily non KVO compliant” change is for the *last* key > of the path — in which case the last object isn’t being observed, just > because it’s the last key. This is where I am getting caught out. As you say it works fine for the last key of the path. It does for me too. I am effectively propagating a C# PropertyChanged event. This approach by itself will never be KVO compliant and will fail when mutating non last components in an observed key path. > > So, in the case of a non-KVO-compliant change to the value of a non-terminal > key path object, the non-KVO-compliance may not be tolerated by the > frameworks. Hence this error message. > > What I suggest you try is to make two properties: “currentStatus” and > “observableStatus”. The second of these would be updated KVO compliantly > (i.e. via its setter) when you know that the first has changed and the change > should be propagated (i.e. in the places where you now trigger the > willChange/didChange notification manually). Code in the ‘submission’ class > can use ‘self.currentStatus’ to get or set the most recent status object; > observers would observe “observableStatus”, of course. Using a proxy property sounds like it might be doable. Thanks Jonathan _______________________________________________ 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
