Thanks Dave. I am now trying to use an array controller. I have set up the array controller and an observer on arrangedObjects, and that gets called during my addition and removal of children, but the change kind is always 1, and there is never anything in the old or new value arrays, so nothing beyond this knows whether it was an insertion or a deletion. I'm not sure exactly how much use that is in managing my other objects.
On 23 Jan, 2011,at 03:54 AM, Dave Fernandes <dave.fernan...@utoronto.ca> wrote:
Undo, which removes the child and triggers my pre and post processing to remove related items
This is the part that doesn't make sense to me. While you certainly have to worry about making sure your view is in sync with you data model, you should not have to update the nodes in your data model. Core data will do that for you on undo and redo. The other things that need to remain in sync during undo and redo are not other nodes - they are some things that are managed at the view and controller layers of the application. I have some background threads that are processing data and need to know when a node is removed, and I have a mapping between the data and a number of front end objects and views, some of which may be animating at the time, as well as an intermediate model layer, and if any of those objects try to access the core data objects when they have been deleted, then all hell breaks loose. Therefore I have been sending notifications before the nodes are removed so that the processing thread can pick up on that and remove the node from the ones it is working on, and the animations can have their connections to the back end and other related objects cleaned up nicely. I don't know how else to accomplish a nice tidy up, since the animations and processing are using other threads, and may try to access the deleted node. I guess the idea of the array controller is that now instead of accessing the children relationship directly I should always go through the array controller's arranged objects, but I'm afraid I still don't get how that would help with managing the nodes disappearing during undo before I knew about it. I guess the core issue may well be at levels above the data layer, but I'm not sure how to get around this. To keep your view in sync, if you put a controller object between it and the data model, then the controller has to worry about when to stop observing the managed object, not your view (and the NS*Controller classes do this). Now your view just has to change state when it observes that the data has changed or gone away. I'm not sure how this relates to my situation. When a node is added, my layout system runs in a background thread, and when it has worked out where the new node is going to go and where the existing nodes need to move to, it moves the existing ones to their new locations, and at that point creates a number of view level objects for the node, and registers the mapping between the node and its view counterpart. So now I have an array controller which lets me know when *something* has already changed. The two issues I see with this are: 1. I have no idea what changed - KVO only tells me that something has changed with my children. 2. It only tells me after the event, and something in either an animation or background processing thread may have already tried to access the deleted node. It may be more efficient if the view simply notes that a change has occurred in observeValueForKeyPath:ofObject:change:context:, and then coalesces all updates in one place such as drawRect: (since observeValueForKeyPath: may get hit several times during the update of a single object). Your view seems to follow all the intermediate changes of the data model within a single event cycle. That seems a bit fragile to me. Sorry, I don't understand what you mean by that or what to do about it. Again, sorry for taking so much time to get this. I hope the curtains will soon part and I will see the light.. Ken._______________________________________________ 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
