[Detrius]

I have a rather complex setup that I'm working on for a project, and the necessary structure of the classes is perplexing me. Technically, this is my first Cocoa application. However, this is a project that needs to be don eventually, so I figured it was a good enough way to learn Cocoa. I'll start with a generalization of what I'm trying to do and then I'll describe what I'm expecting to have to set up.

I'm creating a program that will pull in several different image files and hang on to a reference to those files. This reference will be saved in a single document. In addition, this program will take several images and create a new document type out of those images. This will be saved in a single document along with the references to the original images.

What I'm expecting to have to do: I have created a subclass of NSImage to account for the additional user-input data about these images. I'm starting to think that I'll just be using several instances of NSDictionary to be able to find images that have specific traits as input by the user. I'm just a little bit perplexed about where I need to subclass NSDocument. I haven't found how I would just reference the image documents as opposed to entirely copying them. In addition, I'm not sure whether or not my NSImage subclass also needs to be an NSDocument subclass, since I'm planning on dealing with image documents. However, the references to these images will be stored in a different document, not the original image document. I'm not sure what I need to do about this.

Any input (including a reference to a forum that might be better able to answer this question) is greatly appreciated.

[Brad Brack]

sounds complicated!

Lets see, if I understand what you are asking, I may be able to clarify a few things for you.
First, your subclass of NSDocument should represent your saved project, so it handles the reading and writing of your project document. That project can contain the references to the other files, and one instance of NSDocument is not necessarily a single window (like a simple text editor is).
You don't need an NSDocument subclass to handle each of the images- just have the instances stored in your NSDocument's variables.
Something like this could represent your NSDocument subclass' header file:

@interface yourImageManipulationProjectDoc : NSDocument {
NSMutableArray *images; // add your image references to this array
NSMutableArray *otherWindows; // if you need to display the images in some dynamic list of windows, keep track of them
.... other variables related to your project .....
}
...
- (NSData * )dataRepresentationOfType : (NSString * )type; // this is where you'll iterate through your images and store the image file's names, plus other data that you want to store in your 'project'

- (BOOL)loadDataRepresentation : (NSData * )data ofType : (NSString * )type; // this is where you will load a 'project' and parse out the saved document into the variables, open your windows for each image (plus error checking to make sure that those images are still where the project belives them to be!)
...

------------
So, that is how I would start it off.
Hope this helps, and that I didn't confuse you further!

[ 03-23-2002: Message edited by: Brad Brack ]

[ 03-23-2002: Message edited by: Brad Brack ]

[Detrius]

I do still have several questions. I had figured out something very similar to what you recommended.

with regards to the array of windows--will the NSDocument class not do this already, as I believe I saw that you can add NSWindowControlers with a built in function. Or, is this so that I, myself, can easily access the windows?

about the Images not needing to be an NSDocument, how would I actually open them? --or is there a method in NSImage that will allow me to source the image as a URL or something along those lines?

Along a different line, how do I designate which NSDocument subclass is to be created when "File - New" is selected? I only have one right now (the actual saved information, all grouped into one class), but I'm getting a "Can't create new document" error. I've been looking through some of the tutorials I've done from Hillegaas' book, but I must be missing something. From looking through the code and the Nib files, I haven't come across anything.

Lastly, just to make sure that I've got my information straight: one NSWindowController per Window, one Nib file per NSDocument, but I can do multiple windows per document and per Nib file. Question: are the NSWindowControllers generally instantiated in code or in the nib file? I'm thinking that if it is instantiated in the nib file, then there could only be one instance of a given window per open NSDocument instance.


Anyway, I haven't gotten all the way through the book yet, so I won't bother the board with stuff that I haven't yet read about.

I just tend to be a person that learns better when questions can be asked. It almost seems that no matter how something is written, there is always some other possibility that leaves room for some kind of questioning.

Hopefully, if my theories serve me well, this might be a mid to high end modeling product that hits the market within the next few years. But, it's an individual senior project I'm working on to get a jump start on my career. If you see a killer Mac OS X 3D app come out from UNC-Charlotte next year, you'll all know that I got screwed out of my intellectual property rights...


Thanks for all responses.

[Brad Brack]

> with regards to the array of windows--will the NSDocument class not do this already, as I believe I saw that you can add NSWindowControlers with a built in function. Or, is this so that I, myself, can easily access the windows?

Don't forget- NSDocument does not represent a window- it represents a file (which can be viewed in zero or more windows). So, that being said, because you have a dynamic number of windows for a 'document', you'll need an mutable array of NSWindowControllers- one element for each window for the one NSDocument.

> about the Images not needing to be an NSDocument, how would I actually open them? --or is there a method in NSImage that will allow me to source the image as a URL or something along those lines?

This is the theory- you'll have to put in the logic! For each image that you want opened in a window, you'll add an instance of NSWindowController and store it in your NSWindowController array. The window associated to your NSWindowController can have an image view in it created with interface builder (in a separate nib, if you want). To load the image into a NSImage variable, use [theImage initWithContentsOfFile:@"yourfilename], then with the NSImageView in the window, set [yourImageView setImage:theImage].

> Along a different line, how do I designate which NSDocument subclass is to be created when "File - New" is selected?

If you've changed the name of your document class, then you'll need to change the application settings. Go to the 'Targets' tab and click on the target (or else go to the Project:Edit Active Target menu). Then go to the 'Application Settings' tab. In the 'Document Types', click on the document type and change the Document Class to your new class name. This is also where you can add other document types to your application and have a different NSDocument subclass to handle it.

> Lastly, just to make sure that I've got my information straight: one NSWindowController per Window, one Nib file per NSDocument, but I can do multiple windows per document and per Nib file.

By George, you've got it! (though an NSWindowController theorhetically isn't required to open a window, for your use, it would be handy, and your NSDocument subclass may actually span/control multiple nib files if you want to store your image windows in another nib)

>Question: are the NSWindowControllers generally instantiated in code or in the nib file? I'm thinking that if it is instantiated in the nib file, then there could only be one instance of a given window per open NSDocument instance.

As I mentioned above, you probably will want to set up another nib for the image controller, making each instantiated controller the owner of that nib. So you load a new instance of the secondary nib, which in turn gives you an instantiated controller.

So, that's about all theory and how I would take a stab at it- in practice, you'll probably run into a few things in the process not covered in any book.

> Thanks for all responses.

You're welcome! I just hope I steered you in the right direction as I wished was done to me when I was bumping though this stuff a year ago.

[Detrius]

This is all starting to make A LOT more sense now. I've been thinking about your responses, and I've been continuing to do my own research. I've answered a few of my own questions through research.

Question: what is the purpose of the first responder? What does it do, and what can I do with it?

Why would I need to instantiate an NSWindowController within a nib file? For example, in the nib file for my NSDocument, I have several types of windows that there would only be one of per document. Should I therefore have their controllers instantiated within the Nib, or would it be easier to tweak it and do it by hand in the code?

Should I assume that if there will be multiple instances af a class relative to its parent in the heirarchy, then I should give it its own nib file? This stems back to what was said earlier about the NSImage subclass having its own nib file. Basically, I've noticed that there will be multiple documents per application, and each document gets its own nib file. It's also generally assumed that each document will only have one window. If this document stored multiple items (like my NSImages in the above example), and each of these items would potentially have its own window (or possibly multiple windows), then should this class of items have its own nib file so that the necessary NSWindowControllers can be instantiated enough times? Is that the issue with having multiple nib files? ::

Operating System Level
within this: multiple NSApplications -- each with MainMenu.nib
within NSApplication: multiple NSDocuments -- MyDocument.nib
within NSDocument: multiple NSWhatever -- Whatever.nib

As I understand it, this is what the Nib File's Owner is for. It's a tree structure, a hierarchy. At each level, a nib file is created. Each nib file only has a single File's Owner, but the nib file can be duplicated in memory. If a class is instantiated within a nib file, there can be only one instance of that class, as it is built to control a specific window.


So, should I assume this as a general rule:
if an item will be instantiated only once for a given Nib File's Owner, then put it in the nib file. If it will be instantiated more than once, store it in code within the class associated with that Nib File's Owner and create a new nib file with that class as its owner.


It seems to make sense, but I haven't seen it said anywhere in documentation. It seems to be abstractly said in the description of how NSWindowControllers relate to Nib files.

and everybody says Cocoa is easy... I'd hate to see what Windows is like... maybe it's just the available documentation.

[Detrius]

Is there no one else in this board the truly knows what is going on with Cocoa? (That's the feeling I got when it took two days to get a single reply.)

[havannas]

Originally posted by Detrius:
<STRONG>Is there no one else in this board the truly knows what is going on with Cocoa? (That's the feeling I got when it took two days to get a single reply.)</STRONG>

Detrius, might I suggest: http://cocoa.mamasam.com/

Thats where I would normally look for guidance and examples.

[Brad Brack]

re: Question: what is the purpose of the first responder? What does it do, and what can I do with it?

The first responder is the object that is first in the responder chain! The responder chain is a list of responder objects (e.g. a text field, the window that the text field is in, the menu bar, etc) that may handle an event (e.g. a key being hit, mouse being clicked, etc). If the first responder object doesn't handle the event, the event gets passed to the next responder in the chain until it gets processed. For a given window, you can make an object in that window the first responder - e.g. making a text field the first responder makes it the current editable field.

re: Why would I need to instantiate an NSWindowController within a nib file? For example, in the nib file for my NSDocument, I have several types of windows that there would only be one of per document. Should I therefore have their controllers instantiated within the Nib, or would it be easier to tweak it and do it by hand in the code?

You don't have to set up a window with an NSWindowController. NSWindowControllers make the windows they are controlling more 'document' like, so you can mark the document as edited if something within the NSWindowController should modify the doc, and you can stop the window from closing (in order to bring up a dialog, or something), plus it lets you set up the windows to automatically cascade too. If you, however, plan to subclass NSWindowController and add outlet objects that you want to attach to objects in the window, instantiating the window controller in the nib lets you attach them within Interface Builder...

re: Should I assume that if there will be multiple instances af a class relative to its parent in the heirarchy, then I should give it its own nib file?

Yes- your subclass of your NSDocument (I'll call it the project document) will have that array of (sublasses of) NSWindowControllers - those NSWindowControllers would be the owners of those nibs, but associated with the document. Each time you need to add a new image window for the project, you will load a new instance of that nib, then add it to the array of NSWindowControllers for that document.

re: So, should I assume this as a general rule:
if an item will be instantiated only once for a given Nib File's Owner, then put it in the nib file. If it will be instantiated more than once, store it in code within the class associated with that Nib File's Owner and create a new nib file with that class as its owner.

Not necessarily- there is an argument that you should keep nibs small so that it's quick to load them, however, if you always open all those windows, then sure- store them all in the same nib.

-----

I just reviewed some of the docs- it does look like the [yourDoc makeWindowController] and [yourDoc addWindowController:] will organize them better than my original 'list of windows' array idea, especially since it ought to set the document owner too.