On 01/09/2009, at 12:25 PM, BareFeet wrote:
ahh, now that makes sense. That's what I was missing. I was trying
to add IBOutlets for instance variables but needed to instead add
IBOutlets for the class (eg MyDocument).
Whaaa? You're probably getting your terminology confused, but the
above makes no sense to me. IBOutlets *are* instance variables. You
don't/can't "add" an IBOutlet for an instance variable. The presence
of "IBOutlet" is merely a marker that allows IB to parse the file. If
you look up its definition you'll see it evaluates to nothing.
You are also not adding an IBOutlet for the class. You are adding an
instance variable, tagged as an outlet, which will point to the
MyDocument instance.
Has this been documented anywhere? I couldn't find it. I would have
thought it a common requirement, or is there a better approach to
sharing data between controllers in the same nib?
It must be documented somewhere, but it's also fundamental to the way
Cocoa works with nibs, so usually it's something you learn about very
early on. A better approach? Possibly, but this is generally what I
do, and probably most people do - it's simple, direct and doesn't do
anything very "magic" though I guess nib loading itself can seem quite
magical at first.
When I try to compile the above, I get an error:
expected specifier-qualifier-list before 'MyDocument'
If I change the "MyDocument*" to "id", it works, but what's the
problem?
Did you include the @class MyDocument; line? That's important - it's a
forward declaration, which informs the compiler that the MyDocument*
is merely a pointer, and so it doesn't need to know anything else
about the class - it has all it needs to proceed to lay out this
object. You can use id, which is a bit like void*, an anonymous type
that will shut the compiler up, but it's better to type things
specifically where you can do so, and here is one such place.
#import "MyDocument.h"
Is this really necessary? It compiles without it. I did it anyway.
Yes, it's really necessary. If you want to properly call the methods
of the MyDocument class, the code needs to know what they are. By
typing the_document as id, you allowed the thing to compile using some
built-in assumptions about what the methods (of class 'id') look like,
but typically those assumptions are false, so it might work, or it
might lead to hard to find bugs that keep you guessing for days or
weeks. If you correctly type the ivar as MyDocument*, it then becomes
essential to #import its header in your code in order to call its
methods, but at the same time it eliminates a major source of bugs at
a stroke.
In your code, you can now do things like this, from your controller:
NSString* file = [the_document fileString];
the_document is showing as value nil. It doesn't seem to be linked
to the instance of MyDocument. Am I missing something?
Well, have you actually linked it to the instance of MyDocument? If
these objects exist as part of the nib (which is the simplest
approach) then you link them together in Interface Builder by ctrl-
dragging from one to the other. In the case of the document class,
it's "File's Owner" in the nib. The other controller would typically
be dragged in as an NSObject (blue cube icon) and have its class set
to MyController. IB will display the outlets "the_document" and
"the_controller" and then it's up to you to connect them.
--Graham
_______________________________________________
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 arch...@mail-archive.com
