[V0ID]

Three questions on creating classes in cocoa-java:

When should one subclass from java.lang.Object, and when from NSObject? Should this always be done from IB, or is it OK to do it manually from PB? Finally, after creating a class in IB, must one always instantiate it (from the 'Classes' menu)?

Thanks.

[Seb G]

Should this always be done from IB, or is it OK to do it manually from PB? Finally, after creating a class in IB, must one always instantiate it (from the 'Classes' menu)?

You only have to do it in IB if you want to make connections to other objects you create in IB. For example, you write a class that manages the background music in a game (say MusicController). Your user interface has a button to turn the music on and off. You want to hook up the button's action to a method of your MusicController called StartStopMusic or something like that. In this case you have to declare and instantiate in IB, which creates an instance of your class (i.e. allocates memory etc), and allows you to make the connections to your button. (BTW dragging a button from the palette into you app window 'instantiates', i.e. creates an instance of NSButton)

On the other hand, there are objects that you want to create programatically, i.e. in PB. This could be for example enemy sprites in a game. Your program will have to keep an array of these, but there will be a variable number of them, and they won't be directly connected to any interface item. As you don't know how many of them you will need when you create the interface, you cannot instantiate, i.e. create, all of them in IB. In fact, IB doesn't need to know about your sprites. In this case, you instantiate the sprite objects programatically (i.e. in PB), and you can also declare them in your code.

Summary: Declare and instantiate in IB if you need to connect your objects to other user-interface items, and know how many objects you are going to need. Do it in PB if you don't have to do this, or if you don't know in advance how many objects of that type you will need.

I'm not working in Java myself, but I suppose you can always subclass NSObject unless you want to write platform independent code.

Remarks:
1. Replace 'sprites' by 'employee records' if you are into serious programming.
2. 'Declaring' a class means telling what an object of this class looks like, i.e. 'an object of type "circle" has a centre and a radius'. 'Instantiating' a class object means creating one particular object of that class, i.e. 'generate a "circle" with centre (12,6) and radius 4'.
3. Apologies if you're not new to OOP and find my explanations a bit too schoolteacher-like.

HTH, Seb.

[Ghoser777]

When should one subclass from java.lang.Object, and when from NSObject?

NSObject is a subclass of Object. It really doesn't matter. Just look at the methods provided by each and see if there's anything that NSObject provides that you would like to have in your subclass. Generally, I just subclass Object.

Should this always be done from IB, or is it OK to do it manually from PB?

As stated, that depends on if you want to hook up outlets to your class. If you want to be able to get a reference to your NSTextField object created in IB, then you'll want to create and instantiate the class in IB. You don't HAVE to, as it would be pretty easy to programmatically instantiate one object and instantiate another using IB, and have the second one pass the reference into the first one, but I wouldn't see the point (not that I don't do that sometimes). There's no harm in declaring all your classes in IB if you want to.

Finally, after creating a class in IB, must one always instantiate it (from the 'Classes' menu)?
Thanks.

That depends. When your program starts up, your MainMenu.nib gets loaded, and consequently instantiates any objects you specified to be instantiated. This isn't the only way to have your main class and other classes instantiated, but it is a free and easy way to do so.

If you got any more questions, feel free to ask. I have all this information about Cocoa-Java for some reason

HTH,
F-bacher

[V0ID]

Thanks for the replies.

So creating a class in IB, then generating the files under the 'Classes' menu does nothing more than create a file with a skeleton for the class. And when you create a class, instantiate it and hook it up to an outlet, there is some information stored in the nib file describing the connection? (ie. what textField is hooked up to what class. I see nothing in the file IB generates about the connection).

And it's possible to do the connection stuff manually in PB? Not that it really matters, I'm just interested. Is there some documentation that goes into detail about how nib files work?

[Ghoser777]

So creating a class in IB, then generating the files under the 'Classes' menu does nothing more than create a file with a skeleton for the class.

Essentially, yes. If you create outlets and actions before you create the files, it will also set up those outlets (instance variables) and outlets (instance methods) for you in code. You actually have to implement them to do something with the actions, but as you said it, skeleton code is created.

And when you create a class, instantiate it and hook it up to an outlet, there is some information stored in the nib file describing the connection? (ie. what textField is hooked up to what class. I see nothing in the file IB generates about the connection).

When a nib file is loaded at runtime, it does the object instantiation that you would normally have to do manually. So if you see this:

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
IBOutlet NSTextField myTextField;
</font>[/code]

and you have it hooked up properly in IB to an instance of NSTextField, then when the nib is loaded, essentially this happens:

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
NSTextField myTextField = new NSTextField(...);
</font>[/code]

And it's possible to do the connection stuff manually in PB? Not that it really matters, I'm just interested. Is there some documentation that goes into detail about how nib files work?

It depends on what you mean. You can manually create an NSTextField, and then add it to the content view of an NSWindow (which you can create manually if you like). The nib file is unnecessary to do all the stuff app's do, but it's a really nice convenience. I don't think there's any doc's on the internal workings of nib files, but I may be wrong.

HTH
F-bacher