On 13 Aug 2014, at 23:40, Ken Thomases <k...@codeweavers.com> wrote:
> > You have to issue the -willChange… _before_ the property has changed. That's > because that's KVO's only opportunity to get the value that's about to become > "old" and remove its observations for the properties of that old object. > > So, that pattern of issuing -willChange… followed immediately by -didChange… > with nothing actually changing in between is a sure sign of a problem. > > The solution is annoying but relatively simple. You need to hold a strong > reference to the old object in a property of your own. So, you need a > property "status" that is _not_ just a pass-through to some other API. It > needs to be backed by an instance variable (e.g. _status) that is a strong > reference to the object. Then, when you receive the notification from the > underlying API that something has changed, you fetch the new object from that > API and assign it to self.status. That assignment is KVO-compliant. You > can/should then eliminate your manual -will/didChange… invocations. > That all makes sense. I am effectively just propagating the C# PropertyChanged event. This is fundamentally not KVO compliant. C# also provides a PropertyChanging event, though it is not so commonly implemented. For managed event changes to be KVO compliant in managed code I will have to ensure that the managed layer events are sent in a may that is KVO compliant when they emerge in unmanaged code. 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
