On Nov 18, 2015, at 14:35 , Graham Cox <graham....@bigpond.com> wrote: > > it’s just that if other code changes the attributes dictionary (such as the > Font Manager) then I need these split out properties to trigger their > notifications so that the UI shows the change
I think I understand, finally. No, what you’re doing won’t work. The problem is that if (say) the Font Manager has a pointer to your NSMutableDictionary object, and mutates it — sets a new value for a key — there *will* be a KVO notification** — I believe we know that the standard NSMutableDictionary class issues KVO notifications for value changes, though I’m not sure whether it’s documented — but it won’t be a notification for the dictionary***, it will be a notification for the individual key. This will have no effect (assuming I’m still on track) because nothing is observing the key path that’s getting the notification. Your UI observers are watching yourModel.thingy instead, and your keyPathsForValuesAffectingThingy doesn’t fire for the reason given above. What will work (assuming I’m still on track) is to bind your UI elements to yourModel.dictionaryOfThings.thingy instead of yourModel.thingy. In that case, a Font Manager update to the dictionary will trigger an update that reaches the UI. The hard part comes if you something is observing the dictionary itself (for example, to tell the text system to update when the dictionary changes externally). A UI element update will trigger a KVC notification on path yourModel.dictionaryOfThings.thingy, but *not* on path yourModel.dictionaryOfThings, so the dictionary observer won’t fire. But there’s nothing in your existing sample code to suggest that anything is observing the dictionary like this, except to trigger the model updates on the duplicate properties, which aren’t needed in the scheme I’m suggesting. It’s a while since we’ve discussed KVO vs. NSMutableDictionary on this list, so I may be misremembering how this all works. (Ken can probably straighten that out.) Even if it doesn’t work this way, if you are in charge of creating the NSMutableDictionary initially, you could write a subclass and give it whatever KVO notification behavior you want. Otherwise, you might be able to achieve your goal by adding another set of observers to the dictionary keys themselves. ** Maybe that should be “would”, not “will”, since you have no observers of this. There are no notifications for regular properties unless something is observing them. I’m not sure whether NSMutableDictionary issues notifications unconditionally or knows what keys are being observed. ***There can’t be a notification for the dictionary itself, because the code that’s mutating it doesn’t know what key to use. _______________________________________________ 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
