On 15 May 2008, at 12:54 pm, Johnny Lundy wrote:
Just another note - the reason that I asked this is that I finally
added a second class to my project. I had never had 2 classes in a
project before because I didn't understand how to have them
communicate. Actually, I still don't - I just try everything until
something works.
If you mean this literally, I doubt that it's ever going to work.
Software's like this: there are millions of ways for it to fail, and a
handful of ways for it to work. The chances of stumbling across one of
the working ways in the vast sea of possible non-working ways purely
at random is negligible.
I wrote the interface and implementation files, and the app would
not load. Of course, I had not instantiated the class because
although I knew that myInstance = [MyClass new]; would make an
instance, I did not know where to put this code. It seemed recursive
to put it in the implementation of itself.
So I dragged out an NSObject in IB, named it the class name, and
everything worked. I still don't understand why. I presume it was
that dragging it out instantiated it. Or maybe having an -init
method instantiated it. Class browser doesn't show instances, so
can't check there.
Dragging it out caused it to exist, yes. A nib file contains objects.
When the nib is loaded, those objects are attached to your program as
real live instances.
The reason I want a name for the instance is so I can use it as the
receiver when I send messages to it from another class's methods.
Right, but understand, the name of the object in IB is not this. It is
nothing of any use to your code, nor does it mean anything
significant. It's merely a name - rename it "donkey kong" if you want,
it makes no difference.
In your code, you have, somewhere (in a suitable object):
IBOutlet id myObjectInstance;
In IB, you connect (ctrl-drag) from "somewhere", myObjectInstance to
the object it refers to. "Somewhere" could usefully be File's Owner,
but since for MainMenu.nib this is NSApp(lication), you would need to
be subclassing NSApplication to add the myObjectInstance outlet. Apart
from being not a very good approach, I infer from your email that you
wouldn't know how to do that anyway. Instead you might get further by
using an application delegate, but you would still need to define this
and write code for it before trying to connect to it in IB.
Ultimately, to be useful, an object in IB MUST be connected to an
outlet, or to another object that is connected to an outlet. If not,
there is no way for your code to refer to it - it might exist in
memory but it's an orphan.
To send a message to your object, elsewhere in your code, you can
write [myObjectInstance doSomething];
Maybe you are expecting too much of Interface Builder. Its job is to
build interfaces. It doesn't write any code, and it doesn't do
anything magic. Maybe you'd be better off starting with writing some
non-interface code so you can understand how objects are instantiated,
how they are assigned to variables, and how you send messages to them.
Once you get this, it should be clearer what IB can, and can't do for
you.
hth,
G.
_______________________________________________
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 [EMAIL PROTECTED]
