 |
 |
when to initialize items on a newly loaded nib file?
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Dec 2002
Status:
Offline
|
|
I'm having problems understanding when to initialize instance variables and/or outlets of my objects that are created when a new nib file is opened.
What I have is a main window with a NSTableView in it and when the user double clicks on a row, I open a new nib file with a window that has a NSTableView and NSTextview in it. This new nib file has a controller class which is a subclass of an NSWindowController.
I set the FileOwner of the new nib file to be custom class of this subclass of NSWindowController. In this new nib file that I loaded, I also have a Datasouce/Delegate object which I instatiated using IB. I also created an instance of NSMutableArray in IB.
In IB I created and connected an outlet in both the subclass of the NSWindowController and the DataSource/Delegate object to the instance of NSMutableArray.
With all that I said, I am not sure as to when do I initialize the instance of the NSMutableArray in the new nib file which is an outlet to which the NSWindowController
and DataSource/Delegate is connected to. The DataSource/Delegate objects uses
the NSMutableArray to know what to return for the different datasources and delegate methods to implement.
To my understanding, intialization should occur in the awakeFromNib method after all
connections and objects have been unarchived from the nib file.
Is it right then in my code of the doubleClick of the NSTableView in the main window
to perform the code below:
-(void)doubleClickedFMTable
{
//open the new nib file
FMDetailWinController *newFMController = [[FMDetailWinController alloc] initWithNibName: @"FMDetails"];
//we then set (pass) the array of the current object they selected in the
//tableView in the main window.
[newFMController setFMSolnArray: [fmMacDetail objectForKey: @"fm soln array"]]
// we show the window
[newFMController showWindow: newFMController];
}
Appreciate any suggestions and insight on this... I'm welcome to suggestions of possibly changing my design of how objects are passed/shared among multiple nib files in an application.
Is it common to have a NSMutableArray instance in IB that is connected to outlets of other objects? This was one of the ways that i saw in order to seperate the datasource and delegate as two separate objects and I'm not sure if it is the correct way.
Thanks.
|
|
|
| |
|
|
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Mar 2004
Status:
Offline
|
|
Not sure I can help with everything you are looking for, but here are a few thoughts that might help.
You say that you have instantiated a datasource/delegate object within IB. While I am sure that this could work, it seems like it would take quite a bit of work. Why not use the controller (i.e., the FileOwner) as the datasource/delegate? In this case, initialization of the IBOutlets would be done simply by connecting the outlets in the controller to the controls in IB; nothing else would be required at run time for initialization of these objects.
The NSMutableArray you mention would be either (a) a member of the controller (if there should be one copy per window), or (b) inside some other object that each instance on the controller could talk to (if there should be one shared array). And the controller would implement the data source methods to get/set the table values using this array.
You are right that initialization of data in the controller should normally in the awakeFromNib method, but in the approach I am describing, hooking up the UI does not require any specific initialization (beyond what is done in the nib). On the other hand, I have never created an NSMutableArray (or any other non-UI/controller) objects in the nib file. I am not saying that this could not be done usefully, but off hand it does not seem to be normally desirable.
I hope this is helpful.
|
|
|
| |
|
|
|
 |
|
 |
|
Addicted to MacNN
Join Date: May 2001
Location: Cupertino, CA
Status:
Offline
|
|
I may be misunderstanding some of what you're asking... But NSMutableArray isn't a UI object, so you don't have to use an Outlet to create one. You can just make it an instance variable in your controller and delegate/datasource objects, and initialize it when those objects are initialized.
|
|
|
| |
|
|
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Dec 2002
Status:
Offline
|
|
The reason that I used an nsmutablearray as an outlet was because I'll be honest I don't quite understand on how to seperate the datasource and delegate into two seperate classes. So I used an outlet to have the datasource and delegate as seperate classes and connect them to the nsmutablearray instance object in IB. I then set the nsmutablearray in the awakeFromNib: with data from a file for example.
Most examples that I've seen always have an array(model), datasource and delegate all in one controller/classes which is some a subclass of NSObject and they connect the NSTableView to the same class in IB.
I'm certainly open to changing my design to the suggestions mentioned but first I would like to understand on how for example to seperate my controller, my datasource and delegate into seperate files that need access to the same array(the model) for example.
I guess the way to do it would be to have the array (model) to be a part of the controller class and programmatically create instances of the datasource and delegate classes then connecting them to the NSTableView instance programmatically such as
[someTableView setDataSource: someDataSourceClass];
[someTableview setDelegate: anotherDelegateClass];
I'm I on the right track of thinking?
Thanks in advance for any advice...
Originally posted by itai195:
I may be misunderstanding some of what you're asking... But NSMutableArray isn't a UI object, so you don't have to use an Outlet to create one. You can just make it an instance variable in your controller and delegate/datasource objects, and initialize it when those objects are initialized.
|
|
|
| |
|
|
|
 |
|
 |
|
Addicted to MacNN
Join Date: May 2001
Location: Cupertino, CA
Status:
Offline
|
|
Yup, you can do it that way. Alternatively you can put instances of the controller and delegate/datasource object(s) in your nib and have the controller send the array reference to the delegate/datasource within its awakeFromNib method. I'm not sure what the best practice is if you have delegate/datasource objects that aren't strictly UI related, but either method will work.
|
|
|
| |
|
|
|
 |
|
 |
|
Fresh-Faced Recruit
Join Date: Dec 2002
Status:
Offline
|
|
Thanks for your advice. All of this MVC is beginning to make much more sense now as I go on with my development.
Now I just need to figure out where to release the nstableview's datasource and delegate objects that I allocated in the awakeFromNib: of the NSWindowController subclass.
Cause I think this is not something that the NSWindowController will do for me since as far as I know it will only do the top level objects.
Originally posted by itai195:
Yup, you can do it that way. Alternatively you can put instances of the controller and delegate/datasource object(s) in your nib and have the controller send the array reference to the delegate/datasource within its awakeFromNib method. I'm not sure what the best practice is if you have delegate/datasource objects that aren't strictly UI related, but either method will work.
|
|
|
| |
|
|
|
 |
|
 |
|
Addicted to MacNN
Join Date: May 2001
Location: Cupertino, CA
Status:
Offline
|
|
Okay, the thing to keep in mind is that objects generally will not retain their delegates, and I think that also applies to datasources. You'll probably want to release them in your controller's dealloc method, unless you have a reason to release them at some other time.
|
|
|
| |
|
|
|
 |
 |
|
 |
|
|
|
|
|

|
|
 |
Forum Rules
|
 |
 |
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
 |
 |
 |
 |
|
 |
|