Re: Windows and views and controls, oh my!
Re: Windows and views and controls, oh my!
- Subject: Re: Windows and views and controls, oh my!
- From: Ken Thomases <email@hidden>
- Date: Mon, 05 Sep 2011 11:07:15 -0500
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 (email@hidden)
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:
This email sent to email@hidden