Re: how to programmatically set outlet to controller
Re: how to programmatically set outlet to controller
- Subject: Re: how to programmatically set outlet to controller
- From: Matt Neuburg <email@hidden>
- Date: Sat, 30 Jun 2007 09:11:50 -0700
- Thread-topic: how to programmatically set outlet to controller
On Sat, 30 Jun 2007 01:21:34 -0500, "William Zumwalt" <email@hidden>
said:
>At some point in the execution of my app, the user will do an operation
>which will programmatically create NSTableHeaderView's (and columns) for my
>NSTableView. This subclassed NSTableHeaderView has an outlet in it and I've
>instantiated this class in my Nib window and connected it to a controller.
This could be way off the beam, but it sounds to me like you might want to
drop back ten yards and punt here, by doing some basic reading about
object-oriented programming, because it seems like perhaps you're having
trouble with the fundamental distinction between a class and an instance. A
class is a kind of template, a set of generic instructions for making a
thing. An instance *is* a thing. (That's a gross over-simplification,
because in Objective-C a class is also, in fact, a thing. But bear with me.)
So, the user will "programmatically create" an instance of your
NSTableHeaderView subclass - is that right? If so, that's a thing (an
instance). And in your nib is *another* thing (an instance - as you say,
you've instantiated the class in your Nib window). So the thing the user is
making is totally different from the thing you've got in the nib. So the
thing you've got in the nib is a total waste; it's never being used.
Unfortunately, the one that's never being used is the one that's got the
outlet connected.
What you might want to do is not to let the user "programatically create" an
NSTableHeaderView subclass instance, but rather just hand the user, on
request, the one you've already got in the nib. That way, the outlet will
work, because the thing you're handing to the user is the thing that has the
outlet connected. You can then programmatically *modify* any other features
of this NSTableHeaderView subclass instance, if necessary.
>I somehow need to get the instance of a
>controller that has already been setup when the program was loaded and set
>the outlet for when the header view is created.
>
>This works below, but the problem is that this is a new instance of the
>controller and not the instance that is already setup when the program
>loaded. I'm just not sure how to grab an existing controller and set an
>outlet for the current object at this point.
>
>
>networkController = [[NetworkController alloc] init];
This is *exactly* the same thing I just said before. alloc-init makes a
*new* thing. That isn't what you want. You want an *existing* thing: the
thing you're creating (instantiating) "when the program loaded". What you
want to say is:
networkController = myAlreadyExistingThing;
The trick here is to make the name "myAlreadyExistingThing" point to your
already existing thing. How you do *that* depends upon how the already
existing thing was brought into existence and how you intend to use it.
There are many ways to do this. Basically, "getting a reference" to an
existing thing is the most fundamental and essential part of the art of
Cocoa programming.
For example, if this thing was instantiated in the nib, you might have an
outlet to it from some *other* instance in the nib; you can then pass the
reference around as needed. Another alternative is to implement singleton:
this means that if there is to be only one instance of the class, the class
itself can generate the instance and hand out references to it as requested.
But the overall point that I'm making is that this is very, very basic
stuff. You simply cannot program in Objective-C without a conceptual
vocabulary that includes complete familiarity with the basic notions of
class, instance, pointer (reference), and so on. So it really might help you
to pause and firm up those notions before proceeding, because confusion on
these matters will lead to memory leaks, crashes, mysterious nil outlets,
and so forth.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
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