> On Feb 16, 2015, at 10:24 AM, Dave <d...@looktowindward.com> wrote: > > Thanks for this, it seems to be saying there is no need for a separate Window > Subclass and that the Window Controller Subclass contains all the code needed > to drive the window. I’m a bit confused of when to use an NSWindow and when > to use and NSWindowController? > > The way I had thought to do this was to have: > > LTWMainWindowController.h, .m and .xib files and LTWMainWindow.h, .m and .xib > files. > > Is this the best approach? Or it is better to put the code in the > LTWMainWindow.h, .m and .xib files directly into LTWMainWindowController? > > Or instead of using NSWindowController and NSWindow should I be using > NSWindowController and NSViewController? > > I’m really confused how to lay this out and want to start off on the right > foot.
I am currently in the early stages of rewriting one of my applications following the advice in the same Mike Ash Q&A article. I'll summarize my approach here for whatever help it may give you, and also in the hope of obtaining reactions from Ken and others. My application is a single-window utility application with some complexity in its user interface (a split view containing a number of UI elements, including two tab views with multiple tab view items, one of which has a nested tabless tab view with multiple tab view items). Although I follow Mike Ash's advice, I have separate MainMenu.xib and MainWindow.xib files instead of a single window.xib file. My MainMenu.xib contains the application's menu bar but no window. MainMenu.xib is owned by NSApplication, and NSApplication's delegate outlet is connected to my AppDelegate object, which is included in MainMenu.xib. MainMenu.xib is loaded, its included AppDelegate object is instantiated, and its applicationDidFinishLaunching delegate method is called, all automatically at launch due to the way the standard Main file works. My AppDelegate class implements NSApplicationDelegate protocol methods as needed, and it handles a few other things that are of application-wide relevance. It tends to be fairly small and simple. Because MainMenu.xib contains no window, the application has a menu bar but nothing else up to the point where AppDelegate's applicationDidFinishLaunching delegate method is called. The window is contained in MainWindow.xib, which is owned by my MainWindowController class. The applicationDidFinishLaunching delegate method in AppDelegate loads MainWindow.xib by calling initWithWindowNibName (I don't buy Mike's advice to declare a simple init method), and at this point the application has both a menu bar and a window. The window's Visible At Launch behavior is set in MainWindow.xib, so the window appears when the application is launched and MainWindow.xib is loaded, without having to call showWindow (or you can just call showWindow). In AppDelegate's applicationDidFinishLaunching delegate method, I set the AppDelegate's mainWindowController and window instance variables to the new window controller and to its new window, so that the AppDelegate can refer to them as needed. The MainWindowController implements the outlets and action methods and any delegate methods for the window and all or most of its buttons and other UI elements. It can refer to the menu bar and other things in the AppDelegate as needed by calling NSApp.delegate. In turn, AppDelegate can refer to the window, its UI elements, and the window controller as needed by using AppDelegte's instance variables for them. In order to further compartmentalize my code, each of the more complex views in the window, such as the tab view items, has its own view controller and .xib file. Each view controller is instantiated, the view in the .xib file it owns is loaded, and the view is positioned in the window, all by suitable methods called in the main window controller, typically in the case of tab view items in response to the user clicking a tab or button or choosing a menu item. The main window controller saves instance variables referring to each view when the view is instantiated so that it can communicate with them. In addition, each view gets a reference back to the window controller when the window controller sets the associated property of the view right after instantiating it (or in a custom init method). In answer to one of your questions, you see from the above that you don't need separate window controller .xib and window .xib files. Your window .xib file, which contains your window, will be owned by your window controller, which has the job of controlling the window it owns. You only need separate window.h and .m files if you are subclassing NSWindow, which often is not necessary but is easy to do. If you do subclass it, you still use the same window.xib file but simply change the window's Class setting from NSWindow to your window subclass's name. Your window controller will still control it. In short, there is no such thing as a window controller.xib file; instead, there is a window controller class and the window.xib file that it owns. In answer to another of your questions, you only need separate view controllers if you follow my practice of creating complex views in separate view .xib files, each of which should have its own view controller as described above. Otherwise, you lay out all of your views in the window in your window.xib file, and you control them with suitable code in your window controller. The same answers apply whether or not you follow my practice of creating separate MainMenu.xib and MainWindow.xib files. The only difference is that your menu and window will be in the same .xib file and controlled by the same window controller. You won't need a separate AppDelegate class because the window controller is designated as the application delegate and takes over those duties, including handling the menu bar and the window together. -- Bill Cheeseman - b...@cheeseman.name _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
