• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: will/didChangeValueForKey: Real World Usage
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: will/didChangeValueForKey: Real World Usage


  • Subject: Re: will/didChangeValueForKey: Real World Usage
  • From: Jerry Krinock <email@hidden>
  • Date: Mon, 22 Oct 2007 14:46:11 -0700


On 2007 Oct, 22, at 13:13, I. Savant wrote:

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:

- (NSMutableSet*)gluesSet {
return [self mutableSetValueForKey:@"glues"];
}

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

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: will/didChangeValueForKey: Real World Usage
      • From: Benjamin Stiglitz <email@hidden>
    • Re: will/didChangeValueForKey: Real World Usage
      • From: mmalc crawford <email@hidden>
    • Re: will/didChangeValueForKey: Real World Usage
      • From: mmalc crawford <email@hidden>
References: 
 >will/didChangeValueForKey: Real World Usage (From: Jerry Krinock <email@hidden>)
 >Re: will/didChangeValueForKey: Real World Usage (From: "I. Savant" <email@hidden>)

  • Prev by Date: Re: detecting when an app is beach-balling
  • Next by Date: NSComboBox Suggestions
  • Previous by thread: Re: will/didChangeValueForKey: Real World Usage
  • Next by thread: Re: will/didChangeValueForKey: Real World Usage
  • Index(es):
    • Date
    • Thread