Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!mips!prls!pyramid!leadsv!esl!esl.ESL.COM!dml From: dml@esl.com (Denis Lynch) Newsgroups: comp.sys.next Subject: Re: Outlet to 'global' interface object. Message-ID: Date: 22 Oct 90 18:48:04 GMT References: <406@nwnexus.WA.COM> Sender: news@esl.ESL.COM Reply-To: dml@esl.com Organization: ESL Inc., Sunnyvale, CA Lines: 59 In-reply-to: adonis1@nwnexus.WA.COM's message of 21 Oct 90 04:11:22 GMT In article <406@nwnexus.WA.COM> adonis1@nwnexus.WA.COM (Adonis Corporation ) writes: I have several nibs, each with a file owner object. I would like each file owner object to contain an outlet to a single object contained in yet another nib. However, Interface builder does not seem to allow me to connect an outlet of an object in one nib to an object in another nib. There are several ways to do this. The most obvious one is to remember what OOP and the separate NIB files can do for you, and use them in there "natural beauty." That goes something like this: You have some object, a Mumble, whose job it is to take care of some facet of your application's state. Part of taking care of the state is to allow the user to interact with it. To implement this you have some method of the Mumble class load a NIB section/file. Now keeping in mind that running this part of the application is the Mumble's job, we don't talk to the interface from any other part of the program, but rather use intermediary methods of the Mumble class to perform the Mumble's job. The major advantage of this approach is that when you decide that you want your application to handle more than one Mumble, it's already set up to do that: the Mumble object you create has its own state and interface already encapsulated. This is the whole point of the text editor example in the Interface Builder chapter in the manuals. But that is only one possible reason for wanting to use separate NIB sections. If you just want to use separate interfaces to simplify editing a large static user interface, then all that pretty talk doesn't help. So what you want then is to get parts of your app tied together even though the come from different NIBs. There are three general approaches that will make this easy: 1) You have to load the NIB section in your code somewhere. The "standard" way to do that is with a line like [NXApp loadNibSection: "MyOtherNib" owner: self]; But remember that you typed that line! There's no reason that you have to make self the owner! You could specify NXApp as the owner, or some other controller object in your program. The only problem with this approach is that the owner gets hooked up to *all* the outlets you connected to the file's owner in the NIB file. That may be less modularity than you want. [The mechanism that the Appkit uses for dealing with the owner object is simply sending messages. It doesn't have to be an object of the class you told IB, as long as it responds to the right messages.] 2) A more manual method that gives you more control is to remember how outlets get set: the Appkit sends the owner object a setThisOutlet: method. So you could have the setThisOutlet: method do [someOtherObject setThatOutlet: anObject]; Now each of your outlets can be handled by whatever object you think needs them most. 3) And of course the easiest way is to have the method that loads the NIB section pass on the outlet values to the objects that need them. Hope that helps, Denis Lynch, ESL Inc.