On 07/02/2010, at 5:19 PM, Trygve Inda wrote: > Would you instantiate the (very simple) NSWindowController subclass > (CheckSheetController) in the nib, or just dynamically create it as needed? > Obviously the window would exist in the nib but TableController could have > an outlet to the window (it'd need on to the NSWindowController if I went > that route).
Instantiate it in the nib. You'll need to handle the OK/Cancel buttons so you can do that e.g. by declaring an IBAction for each in the CheckSheetController and hooking it all up in IB. Otherwise you're going to have to set all that up in code - no reason to do that. The tableview still needs an outlet to the CheckSheetController whatever you do, otherwise how is it going to tell it to do its work? At the every minimum it needs to invoke its -window method. A direct outlet to the window is not a good idea. It will force the window to exist in memory whether it's ever used or not. Having an outlet to the controller will only load the window if actually needed. I'd put as much functionality into CheckSheetController as you can that relates to that sheet. That includes showing the window. I usually have this sort of interface in my subsidiary sheet controllers: @interface Subsidiary : NSWindowController - (void) showSubsidiaryWindowOnParent:(NSWindow*) parent forDelegate:(id) delegate; @end @interface NSObject (SubsidiaryDelegate) // informal delegate callback protocol of whatever makes sense - (void) subsidiaryWindow:(Subsidiary*) sub didCloseAndDeliveredThisImportantInformation:(id) something; @end Then the tableview controller will simply hand off to the CheckSheetController using the first method. That method calls [NSApp beginSheet...] and does whatever it needs to do to set up the window. When OK is clicked the checkSheetController fields the modal -sheetDidEnd: callback and then for the OK case (rather than cancel) calls the delegate method you decided it would call, here declared as an informal protocol. In your case it will be a little different as by using bindings there is no need for a delegate callback really, except perhaps to indicate OK or Cancel, but you could also put the sheetDidEnd: callback in the delegate itself (personally I dislike doing that as it makes assumptions about the kind of interface that CheckSheetController actually implements. If you ever decide to change it, you'll have to rev all the classes that use it). However by using bindings that cross the interface between two objects, as I said, you've already blurred the lines of responsibility. If you encapsulate all the UI stuff in the second controller, it avoids overloading the tableview with stuff it really shouldn't know about, and also makes the secondary controller potentially reusable in any similar situation. --Graham _______________________________________________ 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
