On 05/04/2011, at 6:29 AM, Torsten Geise wrote: > - DialogController is of type NSObject and acts a the File's Owner of > Dialog.xib.
This will work, but it's more conventional (and has certain advantages) to subclass NSWindowController instead of NSObject here. After all, you are controlling a window. > > So far, so good. My problem starts with passing objects to the dialog or > passing the content of the NSTextfield back to the caller. In the showDialog > function, I already have an instance to DialogController (instance 1). When > the NIB file gets loaded, it creates a second instance of DialogController > (instance 2) but containing the same instance of "window". Well, you definitely only want one instance. Either you create it, or you have it in the nib, but not both. The usual case is to use NSWindowController and create it yourself, such as calling [[NSWindowController alloc] initWithWindowNibName:<blah>]; This automatically passes itself as File's Owner for the given nib. That said, what you have is OK enough. But if you also added an instance of the controller to the nib, remove it. > When I want to use an Object in the "onOkButtonPressed" function, how can I > set this object in instance #2? [NSBundle loadNibNamed:@"Dialog" owner:self] > does not return a pointer to the instance. In opposite, when "didEndSheet" is > called, I'm back in instance#1 without any knowledge about the value of > NSTextfield of instance#2. Your controller should abstract the functional meaning of the dialog for its clients. By that I mean that it's incorrect to expose the inner parts of the dialog (text fields and so on) to code outside the controller. Instead, you should have methods on the controller for getting information in abstract terms, e.g. -countOfWidgetsString which internally accesses the text field's contents via the IBOutlet. That allows you to complete change the inner design of the controller/dialog without affecting what it *means* to the outside world. Once you do that, the answer to your question should be obvious. You just ask the controller for the information you want, and it gets it by some internal means and returns it. The remaining kink with sheets and other asynchronous dialogs is to have a way to tell the client that the information has been entered and is ready to use. Typically you do this by defining an informal (or formal, if you want to get fancy) delegate protocol and invoking that when the OK button is clicked. The method you call is a simple callback that the delegate can use as its cue to fetch the information it wants from the dialog controller (or you can bundle the information up in some form - a dictionary perhaps - and pass it to the delegate). So typically you start the dialog with a method something like this on the controller: - (void) beginGetWidgetCountDialogOnParentWindow:(NSWindow*) parent delegate:(id) delegate; and when the delegate is called back (you'll need to store the delegate reference in the controller so that it can call it when the OK button gets clicked), you can ask it for its widget count (or whatever). So, bottom line - craft the controller to handle the job it is required to do and DO NOT EXPOSE ITS INTERNALS TO THE OUTSIDE WORLD. --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
