• 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: grouping undo across method calls in CoreData
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grouping undo across method calls in CoreData


  • Subject: Re: grouping undo across method calls in CoreData
  • From: Stamenkovic Florijan <email@hidden>
  • Date: Mon, 05 Oct 2009 09:46:12 -0400

Jim,

An interesting situation. I do not have anything definitive, but just some ideas and comments....

On Oct 05, 2009, at 09:10, Jim Thomason wrote:

-(void) createOrder {
int highOrderIndex = [self getHighestIndexSomeHow];
[self setValue:[NSNumber numberWithInt:highOrderIndex] forKey:@"ordered"];
}

Hm, do operations using primitive accessors also get registered on the undo stack? If not, you could maybe use that approach, so the setting of the "ordered" value would not ever get registered?


Or maybe you could disable / enabled undo registration in createOrder like:

NSUndoManager* um = ...
[um disableUndoCreation];
int highOrderIndex = [self getHighestIndexSomeHow];
[self setValue:[NSNumber numberWithInt:highOrderIndex] forKey:@"ordered"];
[um enableUndoRegistration];


Have you tried something like this? From what I understand you don't need to have the change of the "ordered" value on the undo stack, and either of these could make that happen...

...

How can I deal with this? I've been trying various combinations of
begin/endUndoGrouping, and even turning on and off groupsByEvent, but
I haven't hit the magic incantation yet.

I guess it is tricky dealing with begin/endUndoGrouping when using delayed invoking. Still, AFAIK it should work. Can you elaborate on why it does not?


I also tried popping all references to the newly created object off
the stack and using prepareWithInvocationTarget: with a method that
just drops the object:

...
//at the end of createOrder up above
[undoManager removeAllActionsWithTarget:self];
[[undoManager prepareInvocationWithTarget:self] negateCreation];
}

-(void) negateCreation {
 [[self managedObjectContext] deleteObject:self];
}

That gets me closer - it actually does drop the object immediately
upon undo, but I still have an additional undo state on the stack.

Which extra undo state do you have? What is the registered undo that does nothing?


That is, I can hit undo once and delete my object entirely, but then I
can hit undo a second time, and seemingly nothing happens. At that
point, I can hit redo twice, and two additional objects will appear.
One with a valid order, and one without. I'm not sure if this approach
is a dead-end or not.

No idea... The concept makes sense though.

HTH,
F
_______________________________________________

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


References: 
 >grouping undo across method calls in CoreData (From: Jim Thomason <email@hidden>)

  • Prev by Date: GLSLBasicsCocoaDL sample code
  • Next by Date: [Xgrid] GridMandelbrot Sample gone?
  • Previous by thread: grouping undo across method calls in CoreData
  • Next by thread: Re: grouping undo across method calls in CoreData
  • Index(es):
    • Date
    • Thread