> 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 (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