• 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: willChangeValueForKey, Ivars and Core Data
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: willChangeValueForKey, Ivars and Core Data


  • Subject: Re: willChangeValueForKey, Ivars and Core Data
  • From: Scott Ahten <email@hidden>
  • Date: Tue, 20 Sep 2005 17:03:04 -0400


On Sep 20, 2005, at 12:33 PM, Jim Correia wrote

I wrote a little test app and poked around. It looks like (can't be 100% certain since I don't have the CoreData source :-) any willChangeValueForKey/didChangeValueForKey will cause CoreData to record a snapshot of the object on the undo stack, even if the passed in key is not a modeled attribute.

I created a simple test project as well and had similar results.


This feels wrong to me - you should probably file a bug. (If it is behaving correctly, perhaps we'll find out why.)

Good idea.


If you disable undo registration in your setter, then the document won't be marked dirty, but you'll get a "phantom" undo state which does nothing, and the document *is* marked dirty on redo.


I'm not sure what the workaround is, if any.

Attempts to composite a generic object with an observable property into my entity and binding it to the table does not update the UI unless the entity's accessor for the object calls will/ didSetValueForKey. (which marks the document as dirty) It seems that accessors for entire key path must call will/didSetValueForKey before the change notification is sent.


Unfortunately, I can't just call refreshData on the table view because the class maintains a list of "active" entities instances that may reside in one or more documents. Since each document has it's own table, the class would need to maintain a reference to each table as well. I'll probably have to create a timer per document and use it call refresh the table instead of relying on KVO.

Thanks,

- Scott


- - - :: email@hidden :: http://www.pixelfreak.net - - -

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >willChangeValueForKey, Ivars and Core Data (From: Scott Ahten <email@hidden>)
 >Re: willChangeValueForKey, Ivars and Core Data (From: Jim Correia <email@hidden>)
 >Re: willChangeValueForKey, Ivars and Core Data (From: Scott Ahten <email@hidden>)
 >Re: willChangeValueForKey, Ivars and Core Data (From: Jim Correia <email@hidden>)

  • Prev by Date: NSDateFormatter time zone not "sticking"?
  • Next by Date: Can't get image smoothing to happen
  • Previous by thread: Re: willChangeValueForKey, Ivars and Core Data
  • Next by thread: Re: willChangeValueForKey, Ivars and Core Data
  • Index(es):
    • Date
    • Thread