I'm not sure if using Core Data would make a difference, but I'd
just do this by responding to the menu command by putting up an
NSOpenPanel then processing the filename it returns appropriately. I
don't think there's any magic "proper" way to do this within the
document architecture, except for...
No, I didn't mention Core Data because I thought it would change the
way this was done, just for completeness.
Just list the file types (UTIs) that you can open in your info plist
and map them to different NSDocument subclasses (if indeed a
different document type is used for each different file type) or map
different UTIs to the same class and differentiate the file type
passed in the document's -readFromURL:ofType:error: method. This
latter approach means you don't even need an "Import" menu, it just
integrates into the existing Open file menu, which is more user
friendly in my book - it "just works" rather than the user having to
worry about what "Import" really means and whether, why and when
they need to use it.
Well, I guess it's a separate argument as to whether or not "Import"
should be used instead of "Open". I tend to think of "Import" as being
used to add to an existing document's data (creating one if none
exists), and for data types that are not "native" to the app.
It's easy enough to make my app open more document types, but that
doesn't really get at the core of the problem...how does one add
fundamental commands similar to Open? They're targeted at the first
responder, and it seems that typically, one does not subclass
NSApplication. Who handles these actions when the messages are sent,
in the varying cases of having a document open, vs. no document open,
etc?
--
Rick
_______________________________________________
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
