Am 15.05.2008 um 02:15 schrieb Johnny Lundy:
And if I want to refer by name to that instance in my code, what is the name of the instance?


You don't. What you're doing is the approach taken by other frameworks, like Carbon:

1) Every object in a GUI description file has a unique identifier
2) When your object loads a GUI description file, it gets a pointer to the root object of the loaded GUI 3a) Then you write a huge function that calls some FindViewByUniqueIdentifier() repeatedly to get a pointer to each object and stash pointers to them in your instance variables 3b) Alternately, each function that needs to access an object in the GUI calls this function to get a pointer to stash in a local variable, leading to repeated searches through your object graph

Cocoa works differently in that it has the concept of outlets that take care of step 3. By control-dragging from an outlet "myInstanceVariable" in an object "myObject" to an object "loadedView" in IB, you make a note that IB should call [myObject setValue: loadedView forKey: @"myInstanceVariable"].

So, instead of you asking the hierarchy: "Where is Pete?", the hierarchy tells YOU: "In case you care, Pete is over here" when it loads the NIB and has created the object "Pete".

This may seem backwards, but since every NSObject implements setValue:forKey: already to look up the instance variable with the same name as the key and assign it the given value, this actually means that your instance variables will all be set up with pointers to the loaded objects by the time your awakeFromNib method is called. I.e. you don't have to write that huge function, you just drag from outlets to objects in IB while you're already dragging and clicking to create your GUI.

The object names, as far as I'm aware, are actually only there to help you navigate the objects in a NIB at design time.

Say I drag out an object and set its class to MyClass. IB dutifully names the object MyClass also. So in my code if I code [MyClass somemessage], does that message go to the Class Object or to the instance made in IB? If to the Class Object, how do I code to refer to the instance?

That object goes to the instance. You dragged out an *object*, an instance, so that's what you get. I expected that, myself, so never got confused by the name being the class name, but I can see how one could be.

Also, I found out that IB will not let me make 2 instances of the same Class. In code, I could say myClassInstance1 = [MyClass new]; and MyClassInstance2 = [MyClass new];, but apparently not in IB.

You can make two instances of a class in the same NIB by dragging out two Objects from the palette and seting their custom class. But as you now know, the names are only for designing, and don't really have any use outside that.

This has been a mystery to me for six years now.

Also, the documentation only says about File's Owner that it is the object that loaded the nib file. What is that object, if my nib file just gets loaded at application launch?

Well, the MainMenu.nib, the main NIB file, gets loaded by the single NSApplication object in your application, so that's the File's Owner in that case. In other NIBs, the File's owner is generally the NSWindowController or NSViewController or NSDocument that loaded the corresponding NIB, or if you're using NSNibLoading directly, it's whatever object you passed in as the owner.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de





_______________________________________________

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]

Reply via email to