adonis1@nwnexus.WA.COM (Adonis Corporation ) (10/21/90)
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. The only solution I can think of is to forget Interface Builder and simply use a global id variable to represent the outlet object. But I would much prefer to have Interface Builder support such a design. Does anyone have any suggestions how it might? Thanks.
wisdom@pico.cs.umn.edu (Scott Wisdom) (10/22/90)
>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. The only solution I can think of is to forget Interface Builder >and simply use a global id variable to represent the outlet object. >But I would much prefer to have Interface Builder support such a design. >Does anyone have any suggestions how it might? There are several ways of doing this. I'll describe the easier way here. In Interface Builder, while your in your application nib, go to the Classes Panel and subclass Application. Select the 'Files Owner' in your Objects Panel, then bring up the Attributes Inspector (command-1). Change the objects class from Application to your new application subclass. Now, with the new 'Files Owner' selected, go into the Class Inspector (command-5) and create an outlet. Now connect this outlet to your global object, so the application object will know about it. Unparse the new application class via the Classes panel. Now edit the resulting .h & .m files and add a new method so the files look something like this: myAppSubclass.h: ----------------------------------------------------- @interface myAppSubclass:Application { id theOutlet; } - setTheOutlet:anObject; - getGlobalObject; //the new method ------------------------------------------------------ myAppSubclass.m: ------------------------------------------------------ @implementation myAppSubclass - setTheOutlet:anObject { theOutlet = anObject; return self; } - getGloablObject //the new method { return theOutlet; } ------------------------------------------------------- Now, when you create your objects in other nib modules, just add #import "myAppSubclass.h" at the beginning of the file and you can get the global object any time by sending NXApp a getGlobalObject message: [[NXApp getGlobalObject] performTheGlobalObjectsMethod]; Of course, this isn't the only way to do it, but probably the easiest. It's much more object oriented than using (ugh) actual global variables. This can also be extended to allow a 'global' object to reside outside the sphere of the main 'application' nib and in another nib altogether. I've been forced to do this, but it's a bit more complicated. I'll sumerize that procedure if there's interest. - Scott Wisdom Coda Music Software Hacker wisdom@heckle.cs.umn.edu <<-- Send e-mail here
dml@esl.com (Denis Lynch) (10/23/90)
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.wiml@milton.u.washington.edu (William Lewis) (10/24/90)
In article <DML.90Oct22114804@mozart.esl.com> dml@esl.com writes: >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 ... [stuff deleted] Or, if you load all of the NIB files with owner=NXApp, you can look up the various objects via NXGetNamedObject() (or some similar call). NXApp contains a table somewhere that associates the textual names of all those named objects in your .nib with the actual objects when the .nib is loaded. (Even objects that don't appear in the little .nib window are named; you just have to find the right aspect of the Inspector.) Notice also you can edit the names of the objects, so they don't all have to be named "ByteSwapperInstance" or whatever ... -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"