Re: processPendingChanges and disableUndoRegistration
Re: processPendingChanges and disableUndoRegistration
- Subject: Re: processPendingChanges and disableUndoRegistration
- From: "christophe mckeon gonzalez de leon" <email@hidden>
- Date: Thu, 25 Dec 2008 18:52:13 -0800
thanks for the pointer.
please pardon the rambling, but i'm just trying to
wrap my head around the semantics involved here.
according to Quincey Morris who answered
your question, the way that apple has it in
their tutorial:
dur (disable undo registration)
mmoc (somehow mutate managed object context and possibly register an
undo action)
ppr (process pending requests)
eur (enable undo registration)
would in fact not be so great because
the context could have been dirtied before any
of the above happened, so we could write
mmoc1 -> dur -> mmoc2 -> ppr -> eur
now if i understood correctly, if mmoc1
triggered an undo registration (which we can't know),
then we would have an undesirable undo action.
but, if it didn't register before dur was called, then
this would actually be alright because the ppr
would happen with undo registration disabled,
and so the changes made by mmoc1 would not
be registered for undo. correct?
hence if we did it my way:
mmoc1 -> ppr -> dur -> mmoc2 -> ppr -> eur
then mmoc1 would always register an unwanted
undo, but at least it would be deterministic. correct?
it would seem then that the correct way to
do document initialization, given that we are heeding
Quincey's advice and not trusting core data to give
us a clean slate, would be
mmoc1 ... mmocN -> ppr -> raa (remove all actions)
and it would also seem that in general the code
posted by apple, namely
dur -> mmoc > ppr -> eur
is a very bad idea because any previous mmocs could
non-deterministically be processed after dur and not
be properly be registerd with the undo manager.
whew. is that all right?
thanks again,
_c
On Thu, Dec 25, 2008 at 5:52 PM, Jerry Krinock <email@hidden> wrote:
> I asked almost the same question a couple months ago. Read the replies to
> this:
>
> http://www.cocoabuilder.com/archive/message/cocoa/2008/10/25/220970
>
> and let us know if that does not answer your question.
>
> _______________________________________________
>
> 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
>
_______________________________________________
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