Re: Upgrading NSDocument format, best practice
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