Thank you. That is the crucial issue.
If Aaron says people don't understand it, and I haven't understood it
even after reading all three editions of his book plus the other two
Cocoa books plus the Apple documentation many times, then it must be
difficult.
On May 23, 2008, at 6:17 PM, Steve Weller wrote:
The hang up that I see is that this documentation give no clue as to
the reason for File's Owner's existence.
Exactly. Saying it connects the nib to an object outside the nib
sounds good, but what object is that? Yes, it is the application
instance, the NSApp, which handles run loops and delegate methods
including app launching and app termination. See? I get that. What I
don't get is "connects the owner to all the other objects in the nib."
I don't connect any nib objects to File's Owner, and in fact if you
look at the connections for File's Owner, the only thing it is
connected to is the About... menu item. It isn't connected to any of
my NSController instances, or NSObject instances in the nib.
I have used it to set my class as its delegate so that I could
implement the delegate method applicationWillTerminate:, and that was
great. Easy to understand, it calls respondsToSelector: and then calls
my delegate method. Cool. But as far as the "serves as a proxy for the
object that owns the nib", why does a nib need an owner? Why do I care
who the owner is? My NSArrayControllers can be bound to model objects
without anything going through File's Owner.
Now if what they are trying to say is that I can bind a controller to
File's Owner and it will "see" all the properties of all the objects
in the class that File's Owner is set to, that would be cool. In that
case it is just serving as an instance of a class and can be used to
reach properties of objects of that class.
What problem does it solve?
I think I will have to do my usual reverse-engineering: set its Class
Identity to blank and see what happens to the application.
I'm not talking about the NSDocument instance as owner, or my own
owner set when loading my own nib file. Just the routine, MainMenu.nib.
Fundamentals mean nothing unless they read like a story: you have to
give each thing a reason to exist so that the reader has a place to
mentally hang them.
Well, true, it isn't defined until after they have referred to it
three times, but even then it's the same thing repeated that I already
have memorized and don't understand.
On May 23, 2008, at 12:13 PM, Matt Long wrote:
I'm trying to figure out why the big hang up on needing to
understand it fully. Not understanding it should not prevent you
from developing applications. So why the hangup? What is the actual
problem? Just set your own NSObject based app delegate as the
File's Owner delegate in IB and start adding your code to it.
That's really all you *need* to know.
-Matt
Because it must be very important (in fact, people always tell me I
MUST understand it because it is so fundamental to the Cocoa Core
Application Architecture), and also the fact that six books can't make
me understand it.
My app works without me understanding it; I never touch it except for
delegation as above. That is not the point.
_______________________________________________
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]
