• 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: Upgrading NSDocument format, best practice
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upgrading NSDocument format, best practice


  • Subject: Re: Upgrading NSDocument format, best practice
  • From: "I. Savant" <email@hidden>
  • Date: Wed, 16 Sep 2009 10:15:50 -0400

On Sep 16, 2009, at 9:52 AM, Markus Spoettl wrote:

I have an NSDocument that reads old-format files which it does no longer write. When loading such an old format file, the app warns the user about the format-change and the fact the file can't be read by older versions once saved with the new one.

Unfortunately, producing files in a compatible format is not possible. I know...

This is not at all uncommon. It's extremely difficult (and often quite simply unsustainable) to produce a completely-backward- compatible format.


The problem is most warning messages are quickly dismissed unread.

Yes, but this is a problem that you can't easily solve. Best to minimize the possibility of loss if the warning is ignored.



So in order to avoid that the user accidentally overwrites old- format files he wanted to keep, I make sure the he has to pick a filename when he decides to save the freshly upgraded document.

In my opinion, you're on the right track. I think the simplest solution is to create a new file extension. Forget renaming the file - a different extension implies a different format. Doing this gives you all the mechanisms and warnings for free: marking the old format as "read only" (ie, the app isn't an editor of that format, only a viewer), then providing the new extension as an "editor role extension", when the user saves, I believe the dialog will automatically pop up the Save As dialogue with that format / extension (or the first editor-role extension) selected.

Problem solved (as far as an individual app should attempt to solve it).


To do so I set -fileURL to NIL and tell the document it has been loaded from a different file using -updateChangeCount:

Um ... yuck. :-} It reminds me of all the SciFi shows where the hero jams something into the electronic lock mechanism (or shoots it with an energy weapon) and the door pops open. Worst. Lock. Ever. In reality, such an action is more likely to guarantee the door won't be able to be opened, having affected the mechanism in unexpected (and likely unwanted) ways ...


Similarly, it's generally a bad idea to short-circuit Cocoa mechanisms if you can possibly help it.


I guess my question is, is this the way to do it? Are there alternatives?

Yes. Use the existing Cocoa document mechanisms. Don't shoot at electronic locks. :-)


--
I.S.




_______________________________________________

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


  • Follow-Ups:
    • Re: Upgrading NSDocument format, best practice
      • From: Markus Spoettl <email@hidden>
    • Re: Upgrading NSDocument format, best practice
      • From: "I. Savant" <email@hidden>
References: 
 >Upgrading NSDocument format, best practice (From: Markus Spoettl <email@hidden>)

  • Prev by Date: Upgrading NSDocument format, best practice
  • Next by Date: Re: Upgrading NSDocument format, best practice
  • Previous by thread: Upgrading NSDocument format, best practice
  • Next by thread: Re: Upgrading NSDocument format, best practice
  • Index(es):
    • Date
    • Thread