On Sep 7, 2011, at 11:19 , N!K wrote: > The reason I ask if a window controller is necessary is that I do not plan to > manipulate the window at all. Once it's open, I will leave it alone while > "drawing within" the views until quitting. Also, I will not be manipulating > the views as a whole. Many examples, notably in Hillegas' books, successfully > display views with content in them without using window and view controllers. …
> I think I haven't encountered a need for the use a window controller. The > system loads the nib and window automatically, and I don't know what the > business logic might be. > … > Does this mean that the window and view controllers are somehow necessary > links even though I will not be use them to do anything else? I really don't > want to make a big issue of this. If it's avoidable, I'm simply reluctant to > add more code that I can screw up. On the other hand, if there's something to > be gained (that I'm currently unaware of) for my case I'll go for it. When I > look at the docs, I see what the controllers can do but I don't recognize > anything I want to do. Then I wonder what I'm missing. I had a beautifully written, carefully phrased answer to your post all written, then I accidentally threw it away courtesy of Mail's exciting new "confuse Cancel with Save As Draft" and "make email composition modal" full-screen UI enhancements. <sigh> Ignore view controllers for now. Unless you've moved particular views into their own xib/nib files, you don't need to use them. The fundamental purpose of a window controller is to manage the loading of window nib files. (In many cases, window controllers also get to be the place to put a lot of related code, but what makes it a *window* controller as opposed to just a controller is its nib loading/management functionality.) For a non-document application, if you start from the Xcode project template, you get a MainMenu.xib file that contains your main window already. IMO this is a really lousy approach for the template to take, but if the window is open all the time this is certainly a feasible approach. It also doesn't need a window controller, because the window is loaded automatically by the frameworks code that loads your main menu automatically -- only whole nib files are loaded, and the window is in there with the main menu. In this scenario, you would probably hook up your window button actions to action methods in your application delegate. So, you can create IBOutlet references from your app delegate to your custom views, and have your app delegate message your custom views directly, passing references to the data that needs to be displayed, when the relevant button action methods are called. Alternately, you can code your custom views to *find* your app delegate (either '[NSApp delegate]' or '[[NSApplication sharedApplication] delegate]'), and get the data model from a property you've added to the app delegate. None of that needs a window controller, so if that satisfies you, you're done. Eventually, though, you'll start writing apps where you want to put your window definition in a separate .xib file. In that case, you'll be creating window controllers to load and manage those separate files. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
