Subject: Re: Bypassing Interface Builder
Subject: Re: Bypassing Interface Builder
- Subject: Subject: Re: Bypassing Interface Builder
- From: Erik Buck <email@hidden>
- Date: Thu, 15 May 2008 10:23:54 -0700 (PDT)
> OK - I really don't need the name then, but I am puzzled as to
> how my new class got instantiated. Here's what I did:
> 1. Create the class, the .h and .m files.
Great. This is how Objective-C classes are generally created. Good job.
> 2. Code the ivars, their @property directives, and their
> @synthesize directives.
So far so good. The @property directives expose properties to Interface Builder in much the same way IBOutlet exposed instance variables. Interface Builder will parse your header files and extract the property information.
> 3. Write 2 instance methods plus the -init method. There are no
> class methods, and no IBOutlets.
Fine. -init is usually a good name for a designated initializer. You will need to understand the concept of a designated initializer if you write non-trivial classes. IBOutlets are never required. Interface Builder is able to use @property too.
> 4. Write an -init method that doesn't instantiate anything.
What do you mean ? Do you understand Cocoa's convention of two stage instance creation using a variant of +alloc and a variant of -init ? Have you written any Objective-C code at all before ? I recommend that you write a few simple command line Objective-C programs so you understand basics of the language and conventions of the frameworks.
> 5. There is no +initialize method, as I don't understand it.
> When I have tried to use it, it complains I can't refer to
> ivars.
+ initialize is a CLASS method. You can tell by the '+' instead of the '-' used to declare instance methods. You should learn the difference between class methods and instance methods. This is a basic concept of Objective-C. Apple's on-line Objective-C manual should help you.
> 6. Compile.
If you pass this step you are doing well based on the nature of your questions.
> 7. In IB, make an NSTextField and read in my class header file.
These are two unrelated steps. Also, the current Interface Builder does not require you to explicitly read in a header file. Are you sure you did that ?
> 8. In IB, drag out an NSObject and give it the class name of my
> new class. I did NOT control-drag anything to anything, and
> there are no IBOutlets in my code.
Dragging any object from a "palette" (what does IB call palettes these days?) instantiates (creates an instance) of some object. Interface Builder calls [[SOMECLASS alloc] init] just like you would in your own source code. The value of SOMECLASS depends on which object/icon you drag in IB. If you drag a text field, there is a good chance the value of SOMECLASS will be NSTextField.
Note: You can also instantiate any object by selecting a class in the class browser and using a menu item to instantiate it.
When you instantiate any object, an actual instance of the appropriate class is created right then LIVE in Interface Builder. All of those settings in Interface Builder send messages to the LIVE object in exactly the same way you would send the messages via code.
The LIVE objects are archived to create a nib file. The nib file contains an interconnected graph of archived objects. When a nib file is loaded into your application or into test interface mode of Interface Builder, the LIVE objects are reconstituted from the archive complete with all of their state and interconnections from when they were archived.
When you change the class of an instantiated object (for example when you changes an NSObject instance into an instance of you subclass of NSObject), Interface Builder stores the class name you specified into the nib file along with the archived object. When the object is unarchived into your application or into test interface mode, the normal Cocoa NSUnarchiver behavior allows class substitution. If possible, the unarchived instance created by IB is replaced by an instance of the class you specified. Your custom subclass of NSObject is not linked into Interface Builder so it will not work in test interface mode. However, your subclass is linked into your application, so when the nib is unarchived, the NSObject instance in the nib is replaced by an instance of your class including all of the property bindings and other connections if you made any.
Try working through some simple tutorials.
_______________________________________________
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