On 22 May 2008, at 2:42 pm, Johnny Lundy wrote:
I still don't know how to call one class from another (the reason I
always only have one class in my projects)
You just need a reference to the other class. That might be something
you've created, or obtained from somewhere else.
Example. Suppose in your first class 'MyClass' you want to use a
bezier path object. That is an instance of another class, so you might
do this:
- (void) someMethodOfMyOwnDevise
{
NSBezierPath* myPath = [NSBezierPath bezierPath];
[myPath setLineWidth:2];
}
This snippet shows you two ways to "call" one class from another. In
the first part, you used a class method of the NSBezierPath class to
return an NSBezierPath instance. If you look up the bezierPath method
in the docs, you'll see it has a + symbol in front of it - that means
it's a class method. In the second part, you "called" an instance
method of the NSBezierPath instance which by dint of your variable
naming you decided to call 'myPath'.
You created the reference myPath simply by typing its name, which you
made up. You gave it a type as you are required by the C language to
do by typing NSBezierPath* (a pointer to a NSBezierPath), and you
assigned it a value by using the = operator, as for any C variable
assignment. All that's left is the message to the NSBezierPath class
which is denoted by the expression enclosed by square brackets - *and
that's how you "call" one class from another*.
That's all there is to it. I'm not sure why you'd be expecting this to
be any more difficult than this - it's derived directly from plain C.
If you don't feel comfortable with the term 'object', think of it
(until you get a bit further) as equivalent to 'struct'. The
difference from an actual struct is that you can send a message to the
struct, rather than pass the struct as a parameter to a procedure.
Under the surface, that's EXACTLY what does happen.
Note - there's nothing different about IBOutlets either - IBOutlet is
merely a macro encapsulating absolutely nothing. The real variable
type is placed after the IBOutlet, and just like 'myPath' above, is
nothing but a pointer to an object. If you look at
NSNibDeclarations.h, you'll see this:
#ifndef IBOutlet
#define IBOutlet
#endif
What's it for then? It's just a hint to Interface Builder that this
ivar is something it can use.
If I might make an observation. Your problem is not with Object-C as a
language, it's with object-oriented programming concepts in general.
That's fine, most people coming from a procedural background have this
mental brick wall they need to get over with OOP. I know I did - it
was tough (and at the time the way I learned it was with the Think
Class Library - if you think Cocoa has a steep learning curve, you
ain't seen nothing!). Luckily, there are thousands of books on OOP out
there - any one of them might help you.
hth,
G.
_______________________________________________
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]
