On 2009 Sep 16, at 18:25, Matthew Lindfield Seager wrote:
Someone kindly warned me off-list about taking care when an item is deleted and then re-added by an Undo ... When a user undoes a deletion it calls the primitive accessor which does not emit KVC/KVO notifications.
How about if you calculate the calculatedBalance in a custom setter whenever a user updates/adds/deletes a transaction, and store its value as a regular property instead of a derived property. This way, everything is "in the model". Both the transaction change and the calculatedBalance change will be stored in the undo group, so that when Undo happens, everything gets changed back to original values.
I also get the feeling that this issue is similar to other people's previously discussed issues and that I'm going to need to take over the undo/redo responsibilities from the NSArrayController (as mentioned in this post...
Well, the Wil Shipley School of Undoing Core Data Doodoo teaches a good lesson if your app is like Delicious Library in the sense that you count the number of changes that a user might make on one hand, and therefore write the requisite undo code in a few hours. But the Core Data <-> Undo Manager interaction is, I'd say, another issue.
1) Is my gut feeling about not using primitive accessors to manage observers correct?
Ah, I should have read your code more carefully. Indeed, the part where you invoke will/didSetValueForKey...
NSLog(@"pretending to change calcBalance so observers will know to get it again");
is particularly nasty and always an indication that it's "time to step back".
2) Is there a simple way to override that small aspect of the undo/ redo system (as I'm lazy and everything else is working well) or do I need to implement undo/redo myself?
I don't think you want to do that. When I had similar issues a few months ago [1] I decided that the solution was Custom Setters. My code is full of custom setters. They're brute force and ugly, but they work because they get all the data into the model, where Core Data can get to it and do what Core Data is good at.
I filed a bug on the difficulty of handling derived properties with Core Data and posted its text. You might want to read this [2].
1. http://www.cocoabuilder.com/archive/message/cocoa/2009/2/26/231055 2. http://www.cocoabuilder.com/archive/message/cocoa/2009/2/26/231066 _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
