• 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
doc-based app with more doc types
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

doc-based app with more doc types


  • Subject: doc-based app with more doc types
  • From: Andrea Perego <email@hidden>
  • Date: Tue, 27 Nov 2001 19:30:44 +0100

Hi!

I'm here again to tax the patience of those with more Cocoa experience under their belts!

My questions are related to the management of different document types by a doc-based application. I've browsed through the docs and I've come to guess that to manage two doc types, say typ1 and typ2, one should:

1- declare both types in the ...plist file (sorry, I'm not able to access MacOS X and related docs just now and I don't remember the exact names).

2- provide two subclasses of NSDocument (not instantiated in IB), say MyTyp1Document and MyTyp2Document, whose names must be entered in the file during step 1.

3- create two nib files with the window layouts of both types (e.g., MyTyp1Document.nib & MyTyp2Document.nib), providing two subclasses of NSWindowController (not instantiated in IB).

So far, so good (at least in my newbie imagination) but:

- a standard file menu is provided when one creates a doc-b. app. project in PB, whose items do not refer to more than a doc type (I've read that "New" will trigger the creation of a doc of the first type declared in the list of step 1, and this fact is confirmed by my experiments).

- OTOH, if I've understood well, the actions of these menu items are targeted to a single instance of NSDocumentController, automatically created or "taken" (shared etc.), that responds to them. NSDC is made the NSApplication's delegate.

Now, it seems to me that one should enhance the abilities of NSDocumentController, but the docs state (perhaps in more places) that subclassing NSDC is not recommended and that one should provide a different controller". This sounds a little obscure and threatening to me, and raises some questions:

a) Does it means that one should avoid using NSDC, creating an "ad hoc" controller or that one might use NSDC together with another controller? In the former case, one would - I fear - redo most of the document control machinery from scratch. In the latter case, I can't figure well the relationship between the two controllers (e.g., NSDC is the default NSApplication delegate, but, in taking this way, I believe one should make the custom controller the delegate to filter messages, and the custom controller should respond to the actions of a custom set of file menu items, translating them into appropriate messages to NSDC).

b) If one would subclass NSDC, how should one let NSApplication make it the controller in charge? (I remember some doc where it was written that one had to declare and instantiate the NSDC subclass in the main nib file, but I wasn't able to retrieve it).

c) A further complication in my case arises from the fact that creating an empty document of one of my types is meaningless: my app reads documentsof this type that have been created by other apps and, sometimes, produces new documents with data resulting from operations on the "old" ones.

Maybe what I've written above is pure nonsense: it reveals my present confusional state on this issue. I don't disdain experimenting on my own: after all, it's the best method to acquire experience, but I might use any advice from those who have faced this task before me.

TIA

Andrea Perego
University of Florence - Phys. Dept.


  • Prev by Date: Re: ANN: OCSmart Hacks alpha 1
  • Next by Date: Re: XML and NSCoder
  • Previous by thread: Re: cocoa-dev digest, Vol 1 #899 - 16 msgs
  • Next by thread: Internal Modem Documentation
  • Index(es):
    • Date
    • Thread