• 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: customizing save behavior in doc based apps
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: customizing save behavior in doc based apps


  • Subject: Re: customizing save behavior in doc based apps
  • From: email@hidden
  • Date: Mon, 26 Dec 2005 15:46:29 -0500

mmalc,

Thanks for pointing out that I'm making this too complicated. That was something I was (ironically) hoping to hear.

After a good bit of meddling and reviewing the various docs and fumbling around a bit, my best stab based upon your suggestion is to simply override isDocumentEdited (the only way I would know of hooking into every document edit) with this:

-(BOOL)isDocumentEdited {
// NSLog(@"dirty");

if ([self fileURL])
{
[[self managedObjectContext] save:NULL];
return NO; //does this still qualify as subverting the normal behavior w/ the dirty marker? Without a call to writeToURL:.....I don't of another way to get rid of the save dialog.
}

return [super isDocumentEdited];
}


Based on my limited knowledge and intuition, I thought this (much simpler approach) would work nice and elegantly, but apparently it was a bit too naive. As you probably already know, the save: in between every keystroke causes the disk to churn away and the screen updates much more slowly than otherwise. (And for unsaved documents, the save panel still hangs, but maybe at the moment that's already getting too far ahead.)

So this leads me to believe that isDocumentEdited must not the the best place to save the context after every edit? (But if it is the place, then this leads me back down the road of overriding close (and applicationShouldTerminate) to get the "continuously saved" effect?)


On Dec 26, 2005, at 3:19 AM, mmalcolm crawford wrote:


On Dec 25, 2005, at 9:47 PM, Matthew Russell wrote:

I've done a lot of reading and experimenting on this but just can't get it right. The closest I can seem to come is by doing the following things in my NSPersistentDocument subclass:

You seem to be making this very complicated, an in particular you're subverting the normal behaviour which is to show the dirty marker if there are unsaved changes in the document's managed object context. Try starting by just: for existing documents saving the context after every edit (see the NSPersistentDocument tutorial for discriminating between a new and existing document)...

mmalc

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

This email sent to email@hidden


M.



_______________________________________________
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
  • Follow-Ups:
    • Re: customizing save behavior in doc based apps
      • From: Jim Correia <email@hidden>
References: 
 >customizing save behavior in doc based apps (From: Matthew Russell <email@hidden>)
 >Re: customizing save behavior in doc based apps (From: mmalcolm crawford <email@hidden>)

  • Prev by Date: Re: Cocoa multithreading in C (terrible idea, isn't it?)
  • Next by Date: Re: customizing save behavior in doc based apps
  • Previous by thread: Re: customizing save behavior in doc based apps
  • Next by thread: Re: customizing save behavior in doc based apps
  • Index(es):
    • Date
    • Thread