[RealMadrid]

Hi to all:

I am starting to learn programming MacOS X apps in Cocoa with Obj-C. I have a great amount of experience with common Basic, FutureBasic, RealBasic, JavaScript and a little knowledge of C. I need now to get used to the new concepts of the Cocoa/Obj-C environment. To do that I have read the introduction to Obj-C programming provided by Apple, worked through the currency converter tutorial and looked a a few examples.

Doing that some questions have appeared and I hope some of you experienced programmers can help me to resolve all or some of them. Here I go:

1. When declaring instance variables (or variables in general) that refer to an object they are generally declared with an * what in my understanding means "a pointer to". In some code examples I have found declarations to hold some "NS..." that do not use them. So my question is: When do I have to use the asterisk?. If the answer is for all objects, does that mean there are some "NS..." "objects" that are not really objects?

2. In a class definition (usually the ".m" file) is it necessary to reference all the objects "used" in that code with the "@className" directive? So whenever I write something like .... NSsomething ... I need to put @NSsomething at the beginning of the code?

3. When converting a RealBasic program I need to convert types. Can I use NSString as equivalent to "string". Of course taking into account that NSString is an object and string isn't.

4. Last but not least all examples I have seen use ".nib" files which contain the interface definition. I know this can be useful for the design of applications but for the beginning I would like to start just by coding the interface just to get understanding of how things work together (please don't blame me on that). I have "found" that the application starts in main and returns an NSApplication object. If I want to create a new Window in code would I need to write the code in main (or call a routine from there)?

Thanks in advance. Every piece of help will be appreciated.

[Chuckit]

1. Objects have to be pointed to. However, not everything beginning with the letters NS is an object. For instance, NSRect and NSPoint are structs. You can dynamically allocate an NSRect with malloc() and point to it like you would an object, but that's generally kind of pointless.

2. I'm not entirely sure what you mean. An implementation file for an object has to include the "@implementation MyObject : NSObject"-type line. For any other classes, you just import the proper header files (e.g. "AppKit/NSWindow.h") and you can use them in that file as you like. You don't have to go mentioning classnames all willy-nilly or anything.

3. I don't really know much about RB. I don't see why you couldn't, though. Are there any particular concerns you have about NSString?

4. Why don't you try it? Experience is the best teacher and all. And fortunately, we've got a pretty solid OS that won't die every time your program crashes.

[amonitzer]

2. @class is only required when using circular references (so class A references class B which references class A), because you can't define @interface A before @interface B before @interface A...
3. sure
4. Don't. Nearly no app creates interfaces programatically (except a button here and there perhaps), so why should you try to learn it?

If you want code to be executed at application startup, create a new object in the main nib file, instantiate it and define it as the application's delegate. then implement -applicationDidFinishLaunching: in the class implementation.

[macmike42]

1. To understand the difference between variables, pointers, pointers to pointers (sometimes called handles or multiple indirection), you should really pick up a good book on C. My current favorite is "C: The Complete Reference" by Herbert Schildt, but it is a little dense, really more of a reference than a tutorial. "Learn C on the Macintosh" by Dave Mark is an excellent introduction to the very basics, but you will need a reference after you finish it.

2. The @class directive is used to tell the compiler that a class type exists, without giving any more information. This is most often used in header (.h) files to declare an instance variable or method parameter/return value as a certain class.

For example:

MyObjectA contains an instance variable which is a pointer to an object of type MyObjectB. In MyObjectA.h, you would use the directive @class MyObjectB, so that the compiler knows that type exists. However, in MyObjectA.m, you will need to #import MyObjectB.h so that the compiler can tell MyObjectA all about MyObjectB.

Once again, it is kind of dense, but "Object Oriented Programming and the Objective-C Language" is a great read. It is included with the Dev Tools.

3. When "converting" from REALbasic to Cocoa, do yourself a favor and don't try to "convert" code. Make yourself an outline or flowchart and convert the functionality instead. You will be amazed at how much more sense C and Cocoa make than REALbasic, after you've been at it about a month.

4. Forget coding the interface by hand. Only do this for extremely customized situations (example: the custom windows in Stickies.app). The NIB/Bundle interface is extremely powerful, plus you can manipulate any interface object loaded from a NIB just as if you had created it in code.

Good luck!

[RealMadrid]

Hi:

Thanks to you all repliers!

Your answers have been really usefull and I am going to do good use of them. I am really excited about Cocoa and am really waiting for the moment when start coding for it will be for me as easy as RB.

Thanx again!

[Ibson]

4. Last but not least all examples I have seen use ".nib" files which contain the interface definition. I know this can be useful for the design of applications but for the beginning I would like to start just by coding the interface just to get understanding of how things work together (please don't blame me on that). I have "found" that the application starts in main and returns an NSApplication object. If I want to create a new Window in code would I need to write the code in main (or call a routine from there)?

I think you'll find that you'll never have to touch your main.m file in a GUI-based application. NSApplicationMain() doesn't return an NSApplication object, but returns an integer (0). The main() function of an application must return 0 on success, and > 0 if there was an error. NSApplicationMain() establishes a connection to the window server, starts the main run loop, creates an autorelease pool and various complex stuff like that. As others have said, use nib files to your advantage. If you ever need to create views programatically, you'll use the standard +alloc -init pattern and addSubview: and removeFromSuperview:.