Thanks for the description below. It's good. I, too, am floundering when it comes to specifics that are not shown in examples from Apple or BNR books or websites. I understand the examples, but I don't see how to extend them. So, understanding how the windows and views should be structured together will help me. Perhaps an analogy might make this clearer. It's like having a cookbook with all kinds of well-understood recipes and no idea how to plan a banquet menu that will use the recipes in a good order.
The examples I've seen all show a window with a view in it and how to draw in that view. But I want to put up a window with a couple of views in it and draw in them individually, sometimes clearing and redrawing, sometimes adding more drawing. (Controller code that takes input from pushbuttons and data entry are not a problem.) Do I need an NSWindow Controller at all? Ditto NSViewController? I tried separate drawRect's in controllers but couldn't make them work. An outline of how to do this will be greatly appreciated. I'm using 10.6.8 and Xcode 3.2.4 on an iMac. No iOS. Nick On Sep 5, 2011, at 9:07 AM, Ken Thomases wrote: > 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/pu56ucla62%40alumni.purdue.edu > > This email sent to pu56ucl...@alumni.purdue.edu _______________________________________________ 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
