• 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: Does willChange:valuesAtIndexes:forKey: work correctly?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does willChange:valuesAtIndexes:forKey: work correctly?


  • Subject: Re: Does willChange:valuesAtIndexes:forKey: work correctly?
  • From: Steve Weller <email@hidden>
  • Date: Sat, 17 Mar 2007 17:16:51 -0700


On Mar 16, 2007, at 1:21 AM, Scott Stevenson wrote:


On Mar 15, 2007, at 10:00 PM, Steve Weller wrote:

I have the array controller bound to my class and have methods objectInImageTableDataAtIndex: and countOfImageTableData: so I can provide the data it needs. This all works. The controller happily fills my table.

I feel like I'd need to see this in person to really get what's going on for sure, but a few suggestions:



1. Implement all of the indexed accessors and use those. Specifically:

	-replaceObjectInImageTableDataAtIndex:withObject:


It now works. There were two parts to the fix.

a) I added the interface only for - replaceObjectInImageTableDataAtIndex:withObject:, not the add and remove methods. In fact I did not have to implement any code, because the method was never called and was not needed. So a one line addition to the .h to declare the method and a one line addition to the .m to implement an empty method.

b) I removed the willChange and didChange methods from the loop. Those were confusing the controller and causing it to request all the array elements. There was no need even to call replaceObject in my loop. Changing a member of a mutable dictionary of information that is in my mutable dictionary that implements my cache tells the controller (somehow) that a change has occurred, so it reloads the affected array element and gets the new data.

Perfect. I'm learning that the least code wins when it comes to Cocoa.


You can use this directly inside your loop.

<http://developer.apple.com/documentation/Cocoa/Conceptual/ KeyValueCoding/Concepts/AccessorConventions.html>


2. You also might try:

	id arrayProxy = [self mutableArrayValueForKey:@"imageTableData"];

Which gives you back a proxy object which acts like a mutable array. Changes to that proxy object are picked up by the array controller directly.


3. The combination of 1 and 2. Implement all of the index accessors, then use -mutableArrayValueForKey: to make changes.



Let use know what you find.

    - Scott
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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

-- Bagelturf Blog http://homepage.mac.com/bagelturf/



_______________________________________________

Cocoa-dev mailing list (email@hidden)

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


References: 
 >Does willChange:valuesAtIndexes:forKey: work correctly? (From: Steve Weller <email@hidden>)
 >Re: Does willChange:valuesAtIndexes:forKey: work correctly? (From: Scott Stevenson <email@hidden>)

  • Prev by Date: Re: Preventing default drawing of slider bar in custom NSSlider class
  • Next by Date: NSAttributedString with NSTextTable Can not save with NSArchiver Suggestions
  • Previous by thread: Re: Does willChange:valuesAtIndexes:forKey: work correctly?
  • Next by thread: Core Data & threads [re: Ping: Look for hints for "nested transaction" problem with Core Data]
  • Index(es):
    • Date
    • Thread