I would suggest googling "mmalc bindings" - he's maintained a rather
useful list of examples, I believe two of which demonstrate wiring up
custom views. Perhaps spending time studying those will fit some
pieces together for you.
Well, not really. mmalc's GraphicsBindings has a JoystickView which
seems to maintain KVO by using a setValue:forKeyPath: as the last
step in processing a mouse click. But it's trivial because the value
being observed is only a single value, not an array, and not
generated on the fly.
You can avoid this problem by:
1 - Wrapping (with will/did...) the changes in -setSelectedIndexSet:
property of your view.
2 - Creating a "selectNone" or similar method (called when a click
selects nothing, for example) that calls:
[self setSelectedIndexSet:[NSIndexSet indexSet]];
3 - ONLY modifying the -selectedIndexSet property via
-setSelectedIndexSet: anywhere else in your code.
This funnels everything through your property accessors and so keeps
everything clean and in one place. Hope that helps.
Thanks, I.S. I had considered something like that, but now we're
adding ^even more^ code! Let me repeat that, as is, the code in my
original post works perfectly. If I had not heard lectures from
Apple on this topic, I wouldn't even be worried. If I remember
correctly, the exact admonition was against sending will/did change
as consecutive statements. At least I executed some code in between,
which ^usually^ changes the value. Am I going to add alot of code to
fix something that's not broken?
I'm reminded of a similar situation in Core Data. For a to-many
relationship, NSManagedObject gives me a mutable set and, If I'm not
mistaken, I can insert/remove/replace its contents as I please. Here
is an accessor, which was generated by mogenerator:
Look, it doesn't even send a willAccessValueForKey/
didAccessValueForKey, yet I can insert/remove/change the contents of
this set (not replacing whole thing, as you recommended), and Core
Data observes whatever I did and it all "just works". Is this magic
built into Core Data only?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
