On Sep 5, 2011, at 10:32 AM, William Squires wrote: > While I can create the UI easily enough in IB, what I don't understand is how > to actually load, instantiate, and display the window from my view controller > object.
A common approach is to: * Create a custom subclass of NSWindowController. Since a custom window controller is usually intimately tied to a specific NIB, one usually hard-codes the NIB name in the init method. That is, your custom init method will invoke [super initWithWindowNibName:@"YourNIBName"]. (Note: this is a window controller, which is different from a view controller.) * Create a NIB containing your window. In the Identity inspector, set the class of the File's Owner placeholder to be your custom window controller class. * Connect the "window" outlet of File's Owner to the window in the NIB. If your custom window controller has other outlets, connect them, too. * In the code which knows that it wants to display the window (often the app controller), instantiate your custom window controller class. Then either invoke -showWindow: on it or request its window property and directly manipulate it -- for example, send it -makeKeyAndOrderFront:. > [...] how do I: > > 1) make sure the window isn't displayed until all it's views (controls) have > had a chance to initialize their default (visual) state properly Either the views should obtain their state on demand, such that the very act of drawing themselves makes sure they are showing their proper state, or they should initialize themselves in -awakeFromNib or the like. In other words, this isn't usually something you have to manage manually from the point of view of the code that displays the window nor the window controller. If the window controller does need to set stuff up after the window was loaded, do that in an override of -windowDidLoad. > 2) actually display the window, either modally, or not. Described above. To run a window modally, use -[NSApplication runModalForWindow:]. > 3) if modal, how does my client code make sure it doesn't return from the > operation until the user closes the window (by clicking the close box, or by > dismissing it in code from an IBAction tied to an NSButton whose caption is > "Done" or some such.) -runModalForWindow: won't return until something invokes -stopModal, -stopModalWithCode:, or -abortModal. > 4) Pass information to/from the client code and the view controller? The code which instantiates the window controller should either pass arguments to a custom initializer of your own design or simply invoke methods, such as setters, to configure the window controller. > 5) Prevent the window from closing (if non-modal) if the contents are 'dirty'? Set the window controller to be the window's delegate by connecting the window's delegate outlet to File's Owner in the NIB. Then have the window controller implement -windowShouldClose:. Regards, Ken _______________________________________________ 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
