Re: Bypassing Interface Builder
Re: Bypassing Interface Builder
- Subject: Re: Bypassing Interface Builder
- From: Uli Kusterer <email@hidden>
- Date: Thu, 15 May 2008 08:15:41 +0200
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 (email@hidden)
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:
This email sent to email@hidden