Re: File's owner in nib file
On Jun 8, 2014, at 12:07 PM, Miguel Carvajal krvajal.miguelan...@gmail.com wrote: I created a new NSWindow in interface builder and using a NSWindowController i pr ogrammatically load the window from the nib and show it, but once i close the window, i don' t get it show again. Some digging in stackoverflow revealed me that it happens that way because i have to set the File's Owner of the NSWindow in IB to NSWindowsController. Whether a window will appear or not has nothing to do with File's Owner. Your window is probably marked as Release When Closed in IB. It's shown once the first time, but after closing it it's deallocated and no longer exists so it can't be shown a second time. Turn that off. Documentation on File's Owner: https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html In this case File's Owner is the NSWindowController because it's the NSWindowController that is loading and owns the nib. When you load a nib, your code needs to access certain objects in the nib (via IBOutlets) and your nib may need to set properties (like delegates, data sources, and actions) to objects that exist outside of the nib. When you connect to File's Owner, you're connecting from an object in IB to that object that already exists before nib is loaded. When you connect from File's Owner to an object in the nib, you're setting an outlet in that already existing object to an object in the nib that's being loaded. -- Seth Willits ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: File's owner in nib file
On Jun 8, 2014, at 12:23 PM, Seth Willits sli...@araelium.com wrote: Whether a window will appear or not has nothing to do with File's Owner. Your window is probably marked as Release When Closed in IB. It's shown once the first time, but after closing it it's deallocated and no longer exists so it can't be shown a second time. Turn that off. Kyle pointed something out to me off-list, so now I need to backpedal and change what I said a bit. What I meant was whether or not the File's Owner class in IB is set or not doesn't really matter to the issue at hand, but that's not true because if it's not set then you can't connect the window outlet of File's Owner (your window controller) to the window itself, which of course is critical. So without setting it and connecting the window outlet, the window controller doesn't know about the window. The reason the window is being displayed the first time is probably because it has Visible At Launch checked, which will display the window when the nib loads (Launch is a misleading term, really). Once you've closed it, it can't be reopened because the window controller doesn't know it exists (because the outlet isn't connected) and thus can't tell it to display. On Jun 8, 2014, at 12:28 PM, Miguel Carvajal macarva...@estudiantes.fisica.uh.cu wrote: When you load a nib, your code needs to access certain objects in the nib (via IBOutlets) and your nib may need to set properties (like delegates, data sources, and actions) to objects that exist outside of the nib. When you connect to File's Owner, you're connecting from an object in IB to that object that already exists before nib is loaded. What does it means, the object that already exist before the nib is loaded? Do you refer in this case to NSWindowController instance? Yes. The window controller itself exists before the nib is loaded. This is true of whatever File's Owner would be for any nib being loaded. -- Seth Willits ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: File's owner, outlets and methods
On Aug 13, 2009, at 1:59 PM, Dave Carrigan wrote:
On Aug 13, 2009, at 1:32 PM, Michael de Haan wrote:
The inspector of File's owner in the Custom xib shows, as
expected an outlet ( which is connected) as well as the method
showPanel which is *not* connected. In fact, I am unable to
connect ( if that is the correct terminology) the About
NewApplication to this, or to the File's owner (control-drag), but
am able to do so to the AppController object in the mainMenu.xib
I'm not 100% sure, but it seems like you're saying that you are
trying to connect the About NewApplication menu item in MainMenu.xib
to the Files Owner in Custom.xib?
Can I withdraw my post? :-(
You just made me realize something that I had missed completelyand
I won't say what it is, it's too embarrassing!
If that is the case, you can't do that. All connections must be
between objects and proxy objects within a single xib. The nib
loading process only works on a single nib at a time and doesn't
know anything about what might be in some other nib.
[
**Very** briefly, the set up is as follows.
AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a
method (-(IBAction) showPanel: (id) sender;)
]
So, there are really 2 things happening here?
One is that the About Window's target is established in the
MainMenu.xib ( ie About NewApplication is connected to the method
showPanel).
Secondly, in the About.xib the File's owner is set to the
AppController AND File's owner aboutWindow outlet is now pointed to
the NSPanel object.
I am assuming that this second action is used in the method of
showPanel, where I assume? AppController's outlet is utilized?
-(IBAction) showPanel: (id) sender
{
BOOL successful = [NSBundle loadNibNamed: @About owner: self];
}
Dave...thanks for that insight so far.
___
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
Re: File's owner, outlets and methods
On Aug 13, 2009, at 4:24 PM, Michael de Haan wrote:
[
**Very** briefly, the set up is as follows.
AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a
method (-(IBAction) showPanel: (id) sender;)
]
So, there are really 2 things happening here?
One is that the About Window's target is established in the
MainMenu.xib ( ie About NewApplication is connected to the method
showPanel).
The About _menu_'s target is established in the MainMenu.xib. The
About _window_ is not known in the scope of this xib.
Secondly, in the About.xib the File's owner is set to the
AppController AND File's owner aboutWindow outlet is now pointed
to the NSPanel object.
I am assuming that this second action is used in the method of
showPanel, where I assume? AppController's outlet is utilized?
Not as you've written the showPanel: method below.
An outlet is a property of an object. It's often backed by an
instance variable as its implementation.
Once you connect an outlet to an object in the nib, this connection is
recorded as data within the xib/nib. Later, when that nib is loaded,
Cocoa's nib loading machinery reestablishes the connection by setting
the property on the object. In this case, the outlet is on File's
Owner which, during nib design, is a proxy for an actual object which
is supplied when the nib is loaded. It's the property on this actual
object which gets set during nib loading.
So, after that nib is loaded, the aboutWindow property of your
AppController object has been set to refer to the panel that was
reconstituted from the data in the nib.
Now, some properties will be used by the framework because the
framework was designed with them in mind. For example, the delegate
property of the application object. Hooking this outlet up in a nib
has automatic effects, because the framework makes use of the
application delegate in various ways.
However, properties you define yourself typically won't be
automatically used by the framework. So, setting up a custom outlet
such as aboutWindow in a nib doesn't have secondary effects. It only
has the primary effect of setting that property on that object as the
nib is loaded. From there, it's up to you to make use of that value
in whatever code you write.
-(IBAction) showPanel: (id) sender
{
BOOL successful = [NSBundle loadNibNamed: @About owner: self];
}
Hmm. As you report you've got things working, I'm guessing the panel
in the About.xib is set to Visible At Launch. So, the very act of
loading the nib causes the window to display. If you've also set it
to Release When Closed, then it will properly clean itself up when
it's dismissed.
However:
1) This doesn't make any use of the aboutWindow outlet of the
AppController object. So, there would be no need to set that outlet
up and connect it.
2) Consider what happens if you invoke the About menu when the About
panel is already showing. In fact, try it.
You probably only want to load the nib once, if it hasn't already been
loaded. After that, you only want to reuse the panel that was loaded
that first time. You just have to tell it to show itself. Try to
figure out how that would work. If you have trouble, feel free to ask
again.
I'm not familiar with the Hillegass book, so I don't know if you've
gotten to NSWindowController's, yet. I'm guessing not. At some
point, you will. It should make clear that you should probably use
NSWindowControllers (or subclasses thereof) as File's Owner for nibs
which contain windows or panels. That has some important benefits for
managing the resources of the nib. I won't get into that now. :)
Cheers,
Ken
___
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
Re: File's owner, outlets and methods
On Aug 13, 2009, at 6:36 PM, Ken Thomases wrote:
On Aug 13, 2009, at 4:24 PM, Michael de Haan wrote:
[
**Very** briefly, the set up is as follows.
AppController has an outlet (IBOutlet NSPanel *aboutWindow) and a
method (-(IBAction) showPanel: (id) sender;)
snip.
One is that the About Window's target is established in the
MainMenu.xib ( ie About NewApplication is connected to the method
showPanel).
The About _menu_'s target is established in the MainMenu.xib. The
About _window_ is not known in the scope of this xib.
Of course...stand corrected. That's what I meant but syntax is
important :-)
Secondly, in the About.xib the File's owner is set to the
AppController AND File's owner aboutWindow outlet is now pointed
to the NSPanel object.
I am assuming that this second action is used in the method of
showPanel, where I assume? AppController's outlet is utilized?
Not as you've written the showPanel: method below.
As I drove home I got to thinking ( that's what a good thunderstorm
will do!). I in fact disconnected all references ( by this I mean
IBOutlets in AppController and opened the connection between File's
owner and the NSPanel . It still worked and then it dawned that the
outlet was there **if** I needed to send a message **after** the Nib
was loaded. So, reconnected all, and changed the title of the Panel
after the BOOL successful = [NSBundle loadNibNamed: @About owner:
self]; call, and it suddenly all made sense.
What confused me, as it has done a number of people following this, is
the advice given by Hillegass to set up an outlet in the AppController
class and use the NSBundle class to load the nib. Understandably, I
think most of us expected, therefore , that this outlet **would** play
a role in this setup, but , clearly, I think in this case, it is being
set up for later use, I suspect.
An outlet is a property of an object. It's often backed by an
instance variable as its implementation.
Once you connect an outlet to an object in the nib, this connection
is recorded as data within the xib/nib. Later, when that nib is
loaded, Cocoa's nib loading machinery reestablishes the connection
by setting the property on the object. In this case, the outlet is
on File's Owner which, during nib design, is a proxy for an actual
object which is supplied when the nib is loaded. It's the property
on this actual object which gets set during nib loading.
So, after that nib is loaded, the aboutWindow property of your
AppController object has been set to refer to the panel that was
reconstituted from the data in the nib.
I think I finally get File's owner :-) So, if I understand you
correctly, having set File's owner to the appropriate class ( in this
case AppController) I set the appropriate **proxy** outlet of File's
owner to the object ( in this case NSPanel instance) and when the
Nib is loaded, AppController's IBOutlet gets set to the NSPanel
instance, allowing me to send a message from AppController ( set title
etc) during run-time.
-(IBAction) showPanel: (id) sender
{
BOOL successful = [NSBundle loadNibNamed: @About owner: self];
}
2) Consider what happens if you invoke the About menu when the About
panel is already showing. In fact, try it.
Yep..see above :-)
You probably only want to load the nib once, if it hasn't already
been loaded. After that, you only want to reuse the panel that was
loaded that first time. You just have to tell it to show itself.
Try to figure out how that would work. If you have trouble, feel
free to ask again.
Ken...this may seem like a small thing to you, but this little
exercise, with your help and the others who have answered has given me
some good understanding I did not have before.
Much appreciated.
___
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
Re: File's owner, outlets and methods
On Aug 13, 2009, at 8:26 PM, Ken Thomases wrote: I think I finally get File's owner :-) So, if I understand you correctly, having set File's owner to the appropriate class ( in this case AppController) I set the appropriate **proxy** outlet of File's owner to the object ( in this case NSPanel instance) and when the Nib is loaded, AppController's IBOutlet gets set to the NSPanel instance, allowing me to send a message from AppController ( set title etc) during run-time. Correct, although I would apply the word proxy to File's Owner itself, not its outlets. Of course...again :-) I like to explain File's Owner like this: Ken...thanks for that really illuminating discourse on File's owner. As I look back, I am not sure why this is so confusing, but clearly it's a hurdle that many novices go through ( a quick search of the archives will attest to that)so, hopefully this will be my insight to the next level. With much thanks again. Michael. ___ 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
Re: File's owner as target of button-action
On Oct 7, 2008, at 2:34 PM, Andreas Eriksson wrote: I guess I have misunderstood something here. Is there something special about File's Owner that prevents this from working? There's not enough information here to answer your question. You should post: 1 - How you instantiate your custom NSViewController class and load the nib. 2 - The code listing for the method in question. 3 - Where, exactly, the EXC_BAD_ACCESS is encountered. -- I.S. ___ 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]
Re: File's owner as target of button-action
I guess I have misunderstood something here. Is there something special about File's Owner that prevents this from working? There's not enough information here to answer your question. You should post: 1 - How you instantiate your custom NSViewController class and load the nib. 2 - The code listing for the method in question. 3 - Where, exactly, the EXC_BAD_ACCESS is encountered. My bad. I had managed to release the NSViewController (File's Owner). Thanks! Regards Andreas ___ 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]
Re: File's Owner problems
On Aug 4, 2008, at 11:38 PM, Chris Idou wrote: I've got a class, let's call it Foo, that loads a NIB called Bar. In IB, the File's owner of Bar is set to class Foo. When Foo loads Bar, passing self as the file's owner, Foo.awakeFromNib gets called during the nib loading process. Is that meant to happen? It doesn't make sense to me. http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_3.html mmalc ___ 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]
Re: File's Owner
On May 27, 2008, at 2:02 PM, Quincey Morris wrote: So I was wondering if something like Nib's Root Object might work better. I think, to anyone with even a small amount of exposure to programming topics, root connotes something structural and not something behavioral, which seems appropriate here. That's not good either. Root object has a special meaning in the context of archiving graphs of objects. In particular, it's one of the archived objects, whereas File's Owner is by definition not one of the objects in the nib. On May 27, 2008, at 07:06, Andy Lee wrote: You would send the message to the object you want to be the File's Owner. Instead of: BOOL didLoad = [NSBundle loadNibNamed:@MyNib owner:myObject]; ...you would say: BOOL didLoad = [myObject loadNibNamed:@MyNib]; ...thus leaving out any mention of bundles as an implementation detail. It would then be correct to say that the File's Owner would be the object that loaded the nib. Aside from functional issues, I'm not sure this helps greatly on the conceptual front. It may just shift the question from Which object do I specify for 'owner:'? to Which object do I send the message to? I guess you'd have to test it in the field to find out. :) I was addressing specifically the point you made, which was that File's Owner isn't the object that loaded the nib, it's the object that the object that loaded the nib *says* is the owner. My way, this level of indirection goes away. If you look at the rest of my original suggestion (before the clarification above), I suggested the term Nib's Loader as a replacement for File's Owner, which would connote something behavioral: I'm the object that loaded this nib. I think Nib's Loader would have decreased cognitive load if it had been the term used in the first place (along with the -loadNibNamed: change). I wrote: This way we'd be reinforcing the concept of load a nib in two places, rather than load a nib in one place and own a file in the other. I personally think this would help, mainly if we could go back in time to make the change ;). But maybe it wouldn't. --Andy ___ 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]
Re: File's Owner
On May 27, 2008, at 11:50, Andy Lee wrote: That's not good either. Root object has a special meaning in the context of archiving graphs of objects. In particular, it's one of the archived objects, whereas File's Owner is by definition not one of the objects in the nib. Yes. I was addressing specifically the point you made, which was that File's Owner isn't the object that loaded the nib, it's the object that the object that loaded the nib *says* is the owner. My way, this level of indirection goes away. If you look at the rest of my original suggestion (before the clarification above), I suggested the term Nib's Loader as a replacement for File's Owner, which would connote something behavioral: I'm the object that loaded this nib. Yes, I agree it's simpler, but I really do think you'd need to test it out on some unsuspecting victims before you could be sure it was eliminating the part of the complexity that's actually causing the difficulty. Putting this the other way round, I'm not sure that the answer is to give File's Owner or Nib's Loader behavior that justifies its name, but rather to give it a unobjectionable name that justifies its (lack of) behavior -- if anyone can come up with such a name. ___ 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]
Re: File's Owner
On May 27, 2008, at 3:40 PM, Quincey Morris wrote: Putting this the other way round, I'm not sure that the answer is to give File's Owner or Nib's Loader behavior that justifies its name, but rather to give it a unobjectionable name that justifies its (lack of) behavior -- if anyone can come up with such a name. Connection Point or Nib Connection Point, maybe. The problem is that we're stuck with owner because it's used in the framework API (+[NSBundle loadNibNamed:owner:] is just one place where that terminology is embedded). Cheers, Ken ___ 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]
Re: File's Owner
On May 27, 2008, at 4:40 PM, Quincey Morris wrote: On May 27, 2008, at 11:50, Andy Lee wrote: If you look at the rest of my original suggestion (before the clarification above), I suggested the term Nib's Loader as a replacement for File's Owner, which would connote something behavioral: I'm the object that loaded this nib. Yes, I agree it's simpler, but I really do think you'd need to test it out on some unsuspecting victims before you could be sure it was eliminating the part of the complexity that's actually causing the difficulty. Putting this the other way round, I'm not sure that the answer is to give File's Owner or Nib's Loader behavior that justifies its name, but rather to give it a unobjectionable name that justifies its (lack of) behavior -- if anyone can come up with such a name. Beyond convenience, I think it makes sense conceptually to think of the owner as doing the loading. But if the idea didn't jump out at you that way, maybe it wouldn't to other people either. Anyway, I doubt I'll accomplish much by pushing the idea further, so I'll back out of this thread too. --Andy ___ 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]
Re: File's Owner
As one who has been on the Cocoa road slowly over the last year (not much in the middle, though), it has let me learn and absorb Cocoa terminology and ideas slowly. But the one thing I found weird was File's Owner. I knew what it meant. I knew what it does (and especially after this past week I think I know very very well), but the name throws me off mentally. I liked Nib's Owner. It keeps with the owner tag, but makes it more clear. On May 27, 2008, at 3:40 PM, Quincey Morris wrote: Putting this the other way round, I'm not sure that the answer is to give File's Owner or Nib's Loader behavior that justifies its name, but rather to give it a unobjectionable name that justifies its (lack of) behavior -- if anyone can come up with such a name. Connection Point or Nib Connection Point, maybe. The problem is that we're stuck with owner because it's used in the framework API (+[NSBundle loadNibNamed:owner:] is just one place where that terminology is embedded). Cheers, Ken Alex Kac - President and Founder Web Information Solutions, Inc. - Central Texas Microsoft Certified Partner It is useless for sheep to pass a resolution in favor of vegetarianism while wolves remain of a different opinion. -- William Randolph Inge ___ 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]
Re: File's Owner
Alex Kac wrote: I liked Nib's Owner. It keeps with the owner tag, but makes it more clear. True, but the use of NIB vs. File may be a historical set-in-stone thing that never changed since the NIB is the File (conceptually, of course, since a NIB is a directory with three files), and everyone early on knew that. And for anyone who might still be having issues with differentiating the loader of the NIB vs. the owner as assigned, a way to think of this is what happens in the real world when a person creates a company but assigns legal ownership of it to his/her child. The creator of the company could have kept ownership, but through a deliberate decision, that ownership is transferred to the child. And, as with all types of businesses, not all owners are involved in the same capacity (think of a mom-and-pop restaurant owner vs. Steve Jobs vs. Meg Ryan as a bookstore owner in You've Got Mail), so that's one way you might conceptualize the generality of File's Owner. ___ 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]
[moderator] Re: File's Owner
while the discussion of possible re-positioning of the term file's owner is interesting, discussing it here isn't going to change how it is referred to in the documentation (and for that matter, I doubt it'd be changed from file's owner anyways...) please take it off-list thanks scott [moderator] On May 27, 2008, at 4:47 PM, Ken Thomases wrote: On May 27, 2008, at 3:40 PM, Quincey Morris wrote: Putting this the other way round, I'm not sure that the answer is to give File's Owner or Nib's Loader behavior that justifies its name, but rather to give it a unobjectionable name that justifies its (lack of) behavior -- if anyone can come up with such a name. Connection Point or Nib Connection Point, maybe. The problem is that we're stuck with owner because it's used in the framework API (+[NSBundle loadNibNamed:owner:] is just one place where that terminology is embedded). ___ 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]
Re: File's Owner
Look at the other Currency Converter example (the non bindings one) http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/01Introduction/chapter_1_section_1.html this uses almost the exact same structure you're looking to implement. On May 25, 2008, at 5:01 AM, Roland King wrote: Imagine that I have a model with two properties, number and its square, something much like the currency converter. Ok I've written my model object, it generates events when things change so if you set the number, it computes the square and tells anyone listening about it. View is easy - I have two text boxes. Then I write a controller which has outlets for the two text boxes, and connections to the view so it knows when the text boxes update, and it is able to set properties on a model, and listen to the events on the model. ie lots of glue code. So the idea is I type a number in the text box, the controller gets notified of the change, gets the number, sets the property on the model. The model computes the square and notifies anyone listening that it changed, the controller is listening, sees the change, gets the new square and sets the text box on the view. That's my setup . So now I put the view and the controller in the NIB and I don't instantiate a model object in the NIB because I want to do that in code. This is a standard non-document application. ___ 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]
Re: File's Owner
Well, tell that to the guy who wrote the Currency Converter Using Bindings tutorial. See the last sentence here: This concrete example should help you understand what the value binding’s configuration implies: The content of the text field is bound to the value of the exchangeRate key, which Cocoa bindings finds on the model object using key-value coding. Cocoa bindings knows to look for that key in the model object that is bound to thecontent outlet of the controller specified by the Bind to aspect—in this example, the controller is theNSObjectController instance you configured earlier, whose content outlet points to the Converter object you instantiated in the nib file. And you wonder why I am still confused. That paragraph from Apple directly contradicts what you just said. The Converter object is continually referred to as the Model Object. That is exactly how mine are set up - connected to the Controller Object. The tutorial says nothing about File's Owner. And, if I don't understand something, I will ask why. This is not magic - there is actual computer code behind that File's Owner concept, and it is deterministic, not vague, not abstract, not a philosophical enigma, not random, not ambiguous. If I had the source code I could see what it does. Despite teaching OB/GYN for 17 years, this is why computer science is always my main interest. I've written firmware before we called it firmware. I have never NOT been able to grasp something until this and bindings. Aaron says lots of people have trouble understanding File's Owner, so I can only conclude that it's the documentation, or lack thereof. And yes, I have read that MVC thing over and over and over. On May 25, 2008, at 2:12 AM, [EMAIL PROTECTED] wrote: My NSArrayControllers can be bound to model objects without anything going through File's Owner. Really? That implies that your model is contained within the nib, which is not how MVC is supposed to work. The nib should contain the V (View) and possibly C (Controller) parts of MVC, but it should not contain the M (Model). ___ 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]
Re: File's Owner
On May 25, 2008, at 4:14 AM, mmalc crawford wrote: On May 25, 2008, at 2:01 AM, Roland King wrote: Where do I make the model object and how do I hook it into the controller? I start the application, the Files Owner is the singleton NSApplication, I guess I can override the NIB finished loading method, make the model object there and now I want to call something on the controller like ... -(Controller)hereIsYourModelObject:(Model*)model If you override -awakeFromNib then you'd do so in the controller class, so it would create and set its own model. There's no need to invoke a separate hereIsYourModelObject: method, except in the sense of a setModelObject: accessor. Alternatively you could do it in -init... This is akin to, in the document architecture, the document object setting its model by retrieving it from a file. Another approach is to not put the controller in the nib. Have the controller be the File's Owner. So, the controller is created in code in response to some action or notification or delegate method (e.g. applicationWillFinishLaunching:). Then the nib is loaded, and the controller is passed in as its owner. In the nib, everywhere that you had a connection to or from the controller, you make that connection to or from the File's Owner. Cheers, Ken ___ 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]
Re: File's Owner
On May 25, 2008, at 12:15 AM, Johnny Lundy wrote:
And, if I don't understand something, I will ask why.
Here are some suggestions as to how you might pose your questions:
http://www.catb.org/~esr/faqs/smart-questions.html
This is not magic - there is actual computer code behind that File's
Owner concept, and it is deterministic, not vague, not abstract, not
a philosophical enigma, not random, not ambiguous. If I had the
source code I could see what it does.
But that's where you're leading yourself astray -- there isn't any
source code to see. The nib file is an object graph with a hole in
it. The File's Owner is the hole -- the one thing that *isn't*
created in the nib.
This is a *very rough* approximation:
@interface MyNibManager : NSObject
{
}
- (void)createNibForWindowWithButton:(NSString *)fileName;
- (void)loadNibForWindowWithButton:(NSString *fileName) withOwner:
(id)filesOwner;
@end
@implementation MyNibManager
- (void)createNibForWindowWithButton:(NSString *)fileName {
NSRect contentRect = NSMakeRect(100, 200, 400, 300);
NSWindow *aWindow = [[NSWindow alloc] initWithContentRect:contentRect
styleMask:NSTitledWindowMask backing:NSBackingStoreBuffered defer:NO];
NSRect buttonFrame = NSMakeRect(10, 20, 80, 20);
NSButton *aButton = [[NSButton alloc] initWithFrame:buttonFrame];
[aButton setButtonType:NSMomentaryLightButton];
[aButton setTitle:@Push Me];
[aButton setAction:@selector(myAction:)];
[aButton setTarget:(id)-1]; // pretend kludge to represent File's Owner
// Notice that there's no code for File's Owner itself
[[aWindow contentView] addSubview:aButton];
NSArray *tloArray = [NSArray arrayWithObject:aWindow];
NSDictionary *nib = [NSDictionary dictionaryWithObject:tloArray
forKey:@TopLevelObjects];
[NSKeyedArchiver archiveRootObject:nib toFile:fileName]
}
- (void)loadNibForWindowWithButton:(NSString *fileName) withOwner:
(id)filesOwner {
NSDictionary *nib = [NSKeyedUnarchiver
unarchiveObjectWithFile:fileName];
NSArray *tloArray = [nib objectForKey:@TopLevelObjects];
[filesOwner setWindow:[tloArray objectAtIndex:0]];
NSTextField *aButton = [[[window contentView] subViews] objectAtIndex:
0];
[filesOwner setButton:aButton];
if ([button target] == (id)-1) {
[button setTarget:filesOwner];
}
}
@end
@interface MyFilesOwner : NSObject
{
IBOutlet NSWindow *window;
IBOutlet NSButton *button;
}
@property NSWindow *window;
@property NSButton *button;
- (IBAction)myAction:sender;
@end
@implementation MyFilesOwner
@synthesize window, button;
- (IBAction)myAction:sender {
NSLog(@Button pressed);
}
- (void)dealloc {
[window release];
[button release];
[super dealloc];
}
@end
int main(int argc, char *argv[])
{
NSString *fileName = [NSHomeDirectory()
stringByAppendingPathComponent:@MyInterface.mnib];
MyNibManager *myNibManager = [[MyNibManager alloc] init];
[myNibManager createNibForWindowWithButton:fileName];
MyFilesOwner *filesOwner = [[MyFilesOwner alloc] init];
[myNibManager loadNibForWindowWithButton:fileName ithOwner:filesOwner];
// ...
}
Despite teaching OB/GYN for 17 years, this is why computer science
is always my main interest.
Perhaps it's your background that's causing you the problem. My
father was Dr. J. Selwyn Crawford. I persuaded him to buy a Mac in
1986. He somehow failed to understand (a rarity) that when you use a
word processor you don't have to put Returns at the end of the line...
I've written firmware before we called it firmware. I have never NOT
been able to grasp something until this and bindings. Aaron says
lots of people have trouble understanding File's Owner, so I can
only conclude that it's the documentation, or lack thereof.
I think this is a fallacious conclusion. There are numerous
descriptions of File's Owner, and people typically read many of them.
My perspective, after teaching this for some time, is that some people
simply have difficulty understanding that it's as easy as it is. It's
got to be more complicated...
It isn't.
Interface Builder is a WYSIWYG object graph editor.
A nib file is an archived object graph.
File's Owner is a place-holder for an object created outside of the
nib that is made the owner of the object graph when the object graph
is unarchived (i.e. when the nib file is loaded).
When the nib file is loaded, any connections you made between objects
in the object graph and the File's Owner are reestablished using the
object set to be the owner (typically in -loadNibNamed:owner:).
mmalc
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post
Re: File's Owner
On May 25, 2008, at 6:20 AM, mmalc crawford wrote: On May 25, 2008, at 12:15 AM, Johnny Lundy wrote: And, if I don't understand something, I will ask why. Here are some suggestions as to how you might pose your questions: http://www.catb.org/~esr/faqs/smart-questions.html I hesitate to re-enter this thread, I really do. But I think those of us who have been trying to help might want to re-consider how we've been answering, as well as how the questions have been posed. There have been many fine, thorough answers to Johnny's question. The fact that none of them have seemed to help should tell us something. If I can make a rough analogy, many of our answers have been like different re-implementations of an algorithm. Like the guy on the guillotine in that engineer joke, we each think we see what the problem is. And so we recode the algorithm our own way, run it -- i.e., post our new, improved explanation -- and find it still fails. [1] I submit that instead of recoding the explain File's Owner algorithm, other approaches might lead to a quicker resolution. One alternative is a printf approach to narrowing down the problem. Just as we often tell people to check that variables are what they think they are (D'oh! -- forgot to set an outlet), it might help if we state the relevant logic in *very fundamental* terms and have Johnny indicate *at which point* in the logic he gets lost. This is the approach I tried to take earlier, and although Johnny referred to a line in the Apple docs rather than in my explanation, it led to a very revealing question. He asked: What other objects outside the nib? To me this suggested a FUNDAMENTAL disconnect, possibly at a level that precedes understanding File's Owner. If I were inclined to follow up, I might ask: * Do you now understand there can be objects outside the nib? * Do you understand that your application creates objects, including the application instance, *before* loading MainMenu.nib? * Do you understand that you might want to create and load a nib other than MainMenu.nib? * Do you understand that you may have an object X of your own in your application just *before* you load your nib? * Do you understand that loading the nib will create a bunch of new objects A, B, and C? * Can you imagine that you'd want X to connect to one or more of A, B, and C? Besides the printf approach, another possibility might be a homework approach: write an application that does X, where X highlights the reason for File's Owner. This would require extensive personal followup -- perhaps something a tutor could offer to do for pay. This is not magic - there is actual computer code behind that File's Owner concept, and it is deterministic, not vague, not abstract, not a philosophical enigma, not random, not ambiguous. If I had the source code I could see what it does. But that's where you're leading yourself astray -- there isn't any source code to see. The nib file is an object graph with a hole in it. I assumed Johnny meant the source code that *reads* the nib. I personally don't believe that would help. The File's Owner is the hole -- the one thing that *isn't* created in the nib. First Responder and Application are also not created in the nib. :) Despite teaching OB/GYN for 17 years, this is why computer science is always my main interest. Perhaps it's your background that's causing you the problem. My father was Dr. J. Selwyn Crawford. I persuaded him to buy a Mac in 1986. He somehow failed to understand (a rarity) that when you use a word processor you don't have to put Returns at the end of the line... It's true we all have different blind spots. I've written firmware before we called it firmware. I have never NOT been able to grasp something until this and bindings. Aaron says lots of people have trouble understanding File's Owner, so I can only conclude that it's the documentation, or lack thereof. I think this is a fallacious conclusion. It is a fallacious conclusion for many reasons, one of which is that it also discounts the many sincere efforts of people on this list who have tried to help. --Andy [1] BTW, I am aware of the dangers of using computer concepts as models for human reasoning and human interactions. Take this analogy only for what it's worth. ___ 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]
Re: File's Owner
On May 25, 2008, at 6:31 AM, Andy Lee wrote:
The File's Owner is the hole -- the one thing that *isn't* created
in the nib.
First Responder and Application are also not created in the nib. :)
Indeed, that's why I didn't sleep so well -- something was nagging as
I clicked Send just before dozing off, but I couldn't stay awake any
longer to figure it out...
(Although perhaps I've also got a little too used to looking at a
different sort of nib file over the last couple of months...)
That and the memory management errors in the code:
- (void)createNibForWindowWithButton:(NSString *)fileName {
// ...
[NSKeyedArchiver archiveRootObject:nib toFile:fileName];
[aWindow release];
[aButton release];
}
I hesitate to re-enter this thread, I really do. But I think those
of us who have been trying to help might want to re-consider how
we've been answering, as well as how the questions have been posed.
There have been many fine, thorough answers to Johnny's question.
The fact that none of them have seemed to help should tell us
something.
That's a fair comment, but I'd nevertheless be interested to know if
the code-based explanation helped (Johnny or anyone else).
mmalc
___
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]
Re: File's Owner
On May 25, 2008, at 9:13 AM, Johnny Lundy wrote: Took about a month of 16-hour days to get that down. Experience suggests that this is a suboptimal way to try to learn Cocoa. Some concepts are better understood after quiet reflection. If you're struggling with a concept, find something else constructive to do for a while -- or just go and have a cup of tea -- then come back to it. mmalc (This email sponsored by R. Twining Co Limited.) ___ 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]
Re: File's Owner
On Sun, May 25, 2008 at 2:31 PM, Andy Lee [EMAIL PROTECTED] wrote: If I can make a rough analogy, many of our answers have been like different re-implementations of an algorithm. Like the guy on the guillotine in that engineer joke, we each think we see what the problem is. And so we recode the algorithm our own way, run it -- i.e., post our new, improved explanation -- and find it still fails. [1] What this thread has reminded me of is an ongoing conversation I have with a friend of mine, who refuses to countenance the square root of minus one, because he doesn't think it means anything. I explain to him how useful it can be to admit complex numbers for various real-world situations, but because there exists an algorithm to generate mandelbrots which doesn't ever do sqrt(n) for n0, he thinks this proves that complex numbers are entirely unnecessary and therefore best avoided. It doesn't matter how much you explain that real numbers are imaginary too, or that the square root of 4 apples is also meaningless in a physical sense. He has a sort of emotional investment in the uselessness of complex numbers that completely blinkers him. The difference is, I doubt that this particular friend will ever have reason to do anything that will be made easier by using complex numbers, so I don't suppose his opinion will ever change. But I'm hoping that it's just a matter of time for Johnny. (Maybe when he has occasion to create a document-based app it will become clearer? Although bags I not the one to tell him that NSDocumentController is not designed to mediate between his view and his NSDocument ;] ) Hamish ___ 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]
Re: File's Owner
Thanks to everyone who replied and supplied sample code and anecdotes. I will study these carefully and take notes. N.B. My 16 hours a day comment did not imply that I am losing sleep. I really have been reading and adding features to my project, and creating dozens of test projects, and loading and studying dozens of sample projects, all day since April 1. I have nothing else to do except my annual board certification in OB/GYN and I am procrastinating on that. I do take a few minutes off to watch the News Hour, mow the lawn, and post at Apple. ___ 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]
Re: File's Owner
On 25 May '08, at 11:58 AM, Hamish Allan wrote: What this thread has reminded me of is an ongoing conversation I have with a friend of mine, who refuses to countenance the square root of minus one, because he doesn't think it means anything. It also reminded me of the fact that Isaac Asimov never managed to learn calculus; he said it seemed like some conceptual wall he couldn't get over. Didn't stop him from getting a Ph.D in biochemistry, inventing thiotimoline and positronic AI, and writing a few hundred books on science... I hit a similar wall in number theory, trying to understand finite fields. I managed to visualize how they worked for an hour or two while working on a homework set, but lost it after that, like some ecstatic vision of Heaven shown to a mystic, which he can never remember the details of afterwards. In my case I dropped the class, and later my math major*. I hope that doesn't sound too discouraging. I somehow found plenty of interesting things to work on that didn't involve bijective isomorphisms of finite abelian groups. I don't know what to suggest, Jonny ... I think we've all hit the limits of how vigorously we can wave our hands about the concept in an email thread. Taking a break from it would be a good idea, for all of us. —Jens * to be honest, the math major dropped me. I was kind of crushed, actually. But she later saw the error of her ways, though I eventually married an astronomer. smime.p7s Description: S/MIME cryptographic signature ___ 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]
Re: File's Owner
On May 25, 2008, at 1:30 PM, Andy Lee wrote: Early in his book, Aaron Hillegass suggests ten hours of sleep a night when you're learning something new Given my commitment to lifelong learning, that is now my official excuse for sleeping in late. :-) sherm-- ___ 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]
Re: File's Owner
On May 25, 2008, at 12:02 PM, Hamish Allan wrote: What this thread has reminded me of is an ongoing conversation I have with a friend of mine, who refuses to countenance the square root of minus one, because he doesn't think it means anything. I explain to him how useful it can be to admit complex numbers for various real-world situations, but because there exists an algorithm to generate mandelbrots which doesn't ever do sqrt(n) for n0, he thinks this proves that complex numbers are entirely unnecessary and therefore best avoided. It doesn't matter how much you explain that real numbers are imaginary too, or that the square root of 4 apples is also meaningless in a physical sense. He has a sort of emotional investment in the uselessness of complex numbers that completely blinkers him. The difference is, I doubt that this particular friend will ever have reason to do anything that will be made easier by using complex numbers, so I don't suppose his opinion will ever change. But I'm hoping that it's just a matter of time for Johnny. (Maybe when he has occasion to create a document-based app it will become clearer? Although bags I not the one to tell him that NSDocumentController is not designed to mediate between his view and his NSDocument ;] ) The way I look at it, when you are attempting to learn a new subject you need to be humble. By that I mean you need to jettison some preconceived ideas and probably accept some things without a complete understanding (at least initially). If you are not willing to do that, you will have a hard time assimilating new ideas. Case in point, when I first started taking courses in electrical engineering, I remember some people saying that if you had previous experience with electronics/radio (like for example, you were a Ham radio operator), you might have more difficulty learning some concepts because you had preconceived ideas that were incorrect. (By the way, electrical engineering is where you will use complex numbers.) More to the subject at hand, I thought File's owner was just a mechanism for connecting nib objects to code. Nothing more or less. If I'm missing something, someone can correct me. Jim ___ 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]
Re: File's Owner
On 24 May 2008, at 05:39, Andreas Mayer wrote: I thought, maybe a picture would help: http://www.harmless.de/images/other/files_owner.png Exactly the picture I was about to draw. Johnny Lundy wrote: Saying it connects the nib to an object outside the nib sounds good, but what object is that? The object that loaded the NIB. What object is that? Whichever is passed when the NIB is loaded with [NSBundle loadNibNamed:owner:] e.g. NSApplication probably has code that looks like [NSBundle loadNibNamed:@MainMenu owner:self] You might have a piece of code that reads [NSBundle loadNibNamed:@InspectorWindows owner:inspectorController] ___ 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]
Re: File's Owner
On Sat, May 24, 2008 at 6:49 AM, Paul Sargent [EMAIL PROTECTED] wrote: On 24 May 2008, at 05:39, Andreas Mayer wrote: I thought, maybe a picture would help: http://www.harmless.de/images/other/files_owner.png Exactly the picture I was about to draw. Johnny Lundy wrote: Saying it connects the nib to an object outside the nib sounds good, but what object is that? The object that loaded the NIB. What object is that? Whichever is passed when the NIB is loaded with [NSBundle loadNibNamed:owner:] e.g. NSApplication probably has code that looks like [NSBundle loadNibNamed:@MainMenu owner:self] You might have a piece of code that reads [NSBundle loadNibNamed:@InspectorWindows owner:inspectorController] If your inspectorController is your own custom subclass of NSWindowController, it will make itself the nib's owner if you create it like this: MyInspectorController* ic = [[MyInspectorController alloc] initWithNibName:@ inspectorWindows]; sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net ___ 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]
Re: File's Owner
I dunno. Your book seems to be one of the few, if not the only, that is not on my bookshelf. If you email me your page on File's Owner, I can give feedback. On May 23, 2008, at 9:59 PM, [EMAIL PROTECTED] wrote: I despair that I am unable to adequately explain the concept and utility of File's Owner to you. This disturbs me greatly because I have written a book about Cocoa Programming, and I explained File's Owner in that book. I fear that I have failed. If I can't explain this concept to a very learned programmer, how can I explain it to a true novice. ___ 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]
Re: File's Owner
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 -- Matt Long [EMAIL PROTECTED] http://www.matthew-long.com/ On May 23, 2008, at 12:49 PM, Johnny Lundy [EMAIL PROTECTED] wrote: I decided to once again go verbatim through Cocoa Fundamentals. So far it has been largely uh-huh, yep, but the File's Owner, my nemesis, comes up again. http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_3.html You connect an outlet in Interface Builder, but the procedure starts in Xcode. The following steps describe the procedure: When defining your custom class, declare an outlet by tagging the instance variable with the IBAction qualifier. In Interface Builder, drag a generic object into the top level of the nib file window (if one doesn’t already exist for your custom class). If an instance of your custom class is to be the File’s Owner for the nib file, this step is not necessary. Also, if you’re defining a custom NSView object, select that object instead. Import the custom class into Interface Builder. With the generic object (or File’s Owner) selected, type the name of your custom class in the Class field of the Identify pane of th e Interface Builder inspector. This assigns your custom class as t he class of the selected object. This step has to be done only once. Select your custom instance (or File’s Owner). Right-click or Control-click this object to display the connections panel. Find your outlet under Outlets and drag a connection line from the circle next to the outlet to the object on the user interface that you want that outlet to reference. I sent feedback on this as File's Owner is mentioned several times and not defined. There seems to be some huge problem with File's Owner. Even Aaron Hillegass says that people have trouble understanding File's Owner - and sure enough, when I read his explanation, I remained clueless. I can follow making a generic NSObject set to my custom class, but why File's Owner? My birthday is coming up and if I can understand File's Owner, I will consider that one of the best presents. As usual, I can recite the documentation without understanding it : File's Owner is a proxy object that is set at nib load time to the object that loaded the nib (I don't know what object loaded my nib, so that does not help me). In MainMenu.nib, this is the application instance, which is a shared singleton instance of NSApplication (how all applications can share this is beyond me), which is also set to the global variable NSApp (uhh, OK...). That's all well and good, but what exactly is this thing? Why would I succeed in having an outlet in my class if I set the Class Identity of File's Owner to my custom class? Why should I set File's Owner's Class Identity rather than the Class Identity of a plain NSObject that I drag out of the Library ___ 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]
Re: File's Owner
On Fri, May 23, 2008 at 11:49 AM, Johnny Lundy [EMAIL PROTECTED] wrote: I sent feedback on this as File's Owner is mentioned several times and not defined. There seems to be some huge problem with File's Owner. Even Aaron Hillegass says that people have trouble understanding File's Owner - and sure enough, when I read his explanation, I remained clueless. So ask some questions (personally without all the banter and unneeded tone). I can follow making a generic NSObject set to my custom class, but why File's Owner? You do this so Interface Builder knows what class the owner of the nib will be so it can expose the correct outlets and actions when you attempt to make connections to/from the file's owner proxy object with other objects in the nib. That's all well and good, but what exactly is this thing? It is a proxy object that allows objects instantiated in the nib to be connected with an object outside of the nib, in this case the object that has been specified as the owner of the nib when it was loaded. So the real question you likely have is who is loading my nib? We can only help answer that if you outline more about the nib and the code involved. However as a guess I assume you are talking about MainMenu.nib (default name for the NSMainNibFile entry that you specify in your Info.plist). This nib is loaded by the NSApplication instance the represents your Cocoa application (created when you call NSApplicationMain() in you main entry point). NSApplication is the owner of that nib, hence the file's owner proxy object represents it. Why would I succeed in having an outlet in my class if I set the Class Identity of File's Owner to my custom class? Please restate since I don't follow the question. Why should I set File's Owner's Class Identity rather than the Class Identity of a plain NSObject that I drag out of the Library in IB? See my first answer. -Shawn ___ 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]
Re: File's Owner
On May 23, 2008, at 2:49 PM, Johnny Lundy wrote: I decided to once again go verbatim through Cocoa Fundamentals. So far it has been largely uh-huh, yep, but the File's Owner, my nemesis, comes up again. I tried to answer your File's Owner and NSApp questions last week (copied below). If you can indicate at what point in my explanations you start getting lost, I can try to explain better. Again, I'm sensing a very fundamental disconnect, perhaps more fundamental than you realize. Anybody can recite documentation, so there's no need to tell us that and no need to recite the documentation. I think it would be more helpful to tell us at what *part* of the documentation you start to get lost, and what specifically is confusing about it, perhaps as relates to your other programming experience. If the answer is that you draw a complete blank, then we shouldn't be addressing that issue at all; you need to step back to a more fundamental level and see if you feel fluent at that level. --Andy Here's my reply from last week: On May 15, 2008, at 11:11 AM, Andy Lee wrote: On May 14, 2008, at 10:33 PM, Johnny Lundy wrote: So it's the application instance. I don't understand what the application instance is. I can recite the documentation, which says it is a shared instance of NSApplication, also known as NSApp which is a global variable, none of which help me. To me this indicates a very fundamental disconnect, because what you recited explains NSApp perfectly. I can't tell where the disconnect is, so I'll try to spell this out quickly. No offense intended here -- I honestly don't know where the disconnect is. You are writing a Cocoa application. There is a class called NSApplication that represents the concept of a Cocoa application. That's the purpose of a class in an object-oriented language, to describe a *class* of things conceptually. Classes are usually named for the thing they describe -- hence NSApplication. NSApplication handles the generic things that Cocoa applications do: managing the main menu, managing the window list, dealing with mouse and keyboard events, and so on. Cocoa applications create objects (instances of classes). That's what they do all day. Objects get created, they send messages to each other, they get dealloc'ed. Thousands and thousands of objects, all day long. In your application there is one special object that is an instance of NSApplication. It represents the application itself. I repeat: there is an object in your application that represents the running application itself. There is only one such object, and it is stored in a global variable called NSApp. That is what application instance means. Why would someone bind to File's Owner? What specifically is it? Unlike most other objects in a nib file (First Responder being the exception), File's Owner is not a specific object. It is a placeholder for an owner object that will be specified when the nib file is loaded. You edit a nib file knowing that it will be loaded at some point in your program, and *at that future time* the owner of the file (hence File's Owner) will be specified. The file's owner gives your program access to the objects in the nib file, through the connections you made to it in the nib. I think newcomers sometimes assume that when you load a nib you get some sort of NibObject that you can query to get at the objects in the nib, perhaps using the name you assigned in the nib file. This is an understandable assumption, but you don't get any such object. You need to specify a file's owner for the nib (using the second argument to +loadNibNamed:owner:), and you need to have constructed the nib so it connects the file's owner to at least one of its objects. --Andy ___ 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]
Re: File's Owner
The hang up that I see is that this documentation give no clue as to the reason for File's Owner's existence. What problem does it solve? 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. 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 -- Matt Long [EMAIL PROTECTED] http://www.matthew-long.com/ On May 23, 2008, at 12:49 PM, Johnny Lundy [EMAIL PROTECTED] wrote: I decided to once again go verbatim through Cocoa Fundamentals. So far it has been largely uh-huh, yep, but the File's Owner, my nemesis, comes up again. http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_3.html You connect an outlet in Interface Builder, but the procedure starts in Xcode. The following steps describe the procedure: When defining your custom class, declare an outlet by tagging the instance variable with the IBAction qualifier. In Interface Builder, drag a generic object into the top level of the nib file window (if one doesn’t already exist for your custom class). If an instance of your custom class is to be the File’s Owner for the nib file, this step is not necessary. Also, if you’re defining a custom NSView object, select that object instead. Import the custom class into Interface Builder. With the generic object (or File’s Owner) selected, type the name of your custom class in the Class field of the Identify pane of the Interface Builder inspector. This assigns your custom class as the class of the selected object. This step has to be done only once. Select your custom instance (or File’s Owner). Right-click or Control-click this object to display the connections panel. Find your outlet under Outlets and drag a connection line from the circle next to the outlet to the object on the user interface that you want that outlet to reference. I sent feedback on this as File's Owner is mentioned several times and not defined. There seems to be some huge problem with File's Owner. Even Aaron Hillegass says that people have trouble understanding File's Owner - and sure enough, when I read his explanation, I remained clueless. I can follow making a generic NSObject set to my custom class, but why File's Owner? My birthday is coming up and if I can understand File's Owner, I will consider that one of the best presents. As usual, I can recite the documentation without understanding it : File's Owner is a proxy object that is set at nib load time to the object that loaded the nib (I don't know what object loaded my nib, so that does not help me). In MainMenu.nib, this is the application instance, which is a shared singleton instance of NSApplication (how all applications can share this is beyond me), which is also set to the global variable NSApp (uhh, OK...). That's all well and good, but what exactly is this thing? Why would I succeed in having an outlet in my class if I set the Class Identity of File's Owner to my custom class? Why should I set File's Owner's Class Identity rather than the Class Identity of a plain NSObject that I drag out of the Library ___ 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/bagelturf%40mac.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: File's Owner
On Sat, May 24, 2008 at 12:30 AM, Hamish Allan [EMAIL PROTECTED] wrote: On Fri, May 23, 2008 at 11:17 PM, Steve Weller [EMAIL PROTECTED] wrote: The hang up that I see is that this documentation give no clue as to the reason for File's Owner's existence. From http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CoreAppArchitecture/chapter_7_section_8.html (the first hit on Google for cocoa file's owner): You use the File's Owner object as the conduit for connections between objects in the nib file and objects outside of it. which then point to *Further Reading:* You can find out more about nib files (including how to dynamically load them) by reading *Resource Programming Guidehttp://developer.apple.com/documentation/Cocoa/Conceptual/LoadingResources/index.html#//apple_ref/doc/uid/1051i *which explains the anatomy of a nib file: About the File's Owner One of the more important concepts to understand when building your nib files is what the File's Owner object represents. In Interface Builder, the File's Owner object that appears in the nib document window is a proxy for an object that your application will provide at runtime. When you subsequently load a nib file into your application, your code can specify an actual object to take the place of the File's Owner proxy. When you do, any nib file connections to File's Owner are automatically made to the object you provide (assuming it has the correct outlets and actions). The File's Owner object is one of the primary connections your application has to the contents of a nib file. File's Owner can be any object in your application but is most often set to the controller object that manages the corresponding user interface objects in the nib file. By using File's Owner in this way, you can isolate the details of your user interface to your controller object and let it manage the interactions with other parts of your application. Indeed, there is no clue ;-) -- Julien ___ 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]
Re: File's Owner
On May 23, 2008, at 5:30 PM, [EMAIL PROTECTED] wrote: Message: 3 Date: Fri, 23 May 2008 16:55:13 -0400 From: Andy Lee [EMAIL PROTECTED] Subject: Re: File's Owner To: Cocoa-dev cocoa-dev@lists.apple.com Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes On May 23, 2008, at 2:49 PM, Johnny Lundy wrote: I decided to once again go verbatim through Cocoa Fundamentals. So far it has been largely uh-huh, yep, but the File's Owner, my nemesis, comes up again. I tried to answer your File's Owner and NSApp questions last week (copied below). If you can indicate at what point in my explanations you start getting lost, I can try to explain better. Again, I'm sensing a very fundamental disconnect, perhaps more fundamental than you realize. Anybody can recite documentation, so there's no need to tell us that and no need to recite the documentation. I think it would be more helpful to tell us at what *part* of the documentation you start to get lost, and what specifically is confusing about it, perhaps as relates to your other programming experience. The point at which after it says the proxy is filled in at runtime with the object that was set as the owner, so that the nib objects can communicate with other objects outside the nib*. What other objects outside the nib? I have nothing connected to File's Owner except the delegate, and looking at File's Owner's off the shelf connections, the only one it has is to the About menu item. So I don't see why any object outside the nib could use File's Owner to find out about objects inside the nib, since File's Owner isn't connected to any objects inside the nib (except the About... menu item). So I understand it's a proxy, I understand it has an object it knows as its owner, I know the standard owner is an instance of NSApplication aka NSApp global variable, but what I do not get is why I need this thing, or how it is needed to connect the rest of the nib objects with an object outside the nib. What object outside the nib? If the answer is that you draw a complete blank, then we shouldn't be addressing that issue at all; you need to step back to a more fundamental level and see if you feel fluent at that level. I draw a blank at understanding what it does. I come from a systems programming, BS and MS in CS, from Brown, and all-procedural background - assembler in 360, assembler in Meta-4 minicomputers doing 3-D graphics, taught by Andries van Dam if that means anything, the usual litany of procedural languages - Fortran, Basic, PL/I, PL/C, our own compiler design close to PL/I but faster, C, (no C++ or Java), complete graphics system in assembler like QuickDraw was, visited PARC and saw SmallTalk, Snobol, Cobol, MPW/MacApp, 4D databases, 6502 assembler for processing real-time NMI interrupts for data acquisition on the Apple II, Pascal on the early Macs, then since the introduction of OS X, several Carbon apps programming the device manager, several Cocoa apps, one ported to that platform Apple has that we can't talk about, numerous AppleScript Studio apps, which used AppKit extensively, tableViews and data sources for them, buttons, target/ action and outlets, and attended WWDC four times as well as maintaining a Select ADC membership for at least 6 years now and reviewing all the WWDC videos on Tiger and Leopard recently. Whew. That was all for either school or hobby - only worked one summer as a real-time systems programmer for Foxboro Corp in Massachusetts before leaving for med school. But I don't understand File's Owner. Everything else that I listed up there, I understood. --Andy Here's my reply from last week: On May 15, 2008, at 11:11 AM, Andy Lee wrote: On May 14, 2008, at 10:33 PM, Johnny Lundy wrote: So it's the application instance. I don't understand what the application instance is. I can recite the documentation, which says it is a shared instance of NSApplication, also known as NSApp which is a global variable, none of which help me. To me this indicates a very fundamental disconnect, because what you recited explains NSApp perfectly. I can't tell where the disconnect is, so I'll try to spell this out quickly. No offense intended here -- I honestly don't know where the disconnect is. You are writing a Cocoa application. There is a class called NSApplication that represents the concept of a Cocoa application. That's the purpose of a class in an object-oriented language, to describe a *class* of things conceptually. Classes are usually named for the thing they describe -- hence NSApplication. NSApplication handles the generic things that Cocoa applications do: managing the main menu, managing the window list, dealing with mouse and keyboard events, and so on. Cocoa applications create objects (instances of classes). That's what they do all day. Objects get created, they send messages to each
Re: File's Owner
John - I'd like to be able to describe the concept of File's Owner and First Responder to people clearly. I don't think I would have described it any differently than Key Thomases did early today. I've copied his explanation below. Did you find Ken's explanation helpful? Jon Hess On May 23, 2008, at 12:33 PM, Ken Thomases wrote: On May 23, 2008, at 1:49 PM, Johnny Lundy wrote: As usual, I can recite the documentation without understanding it : File's Owner is a proxy object that is set at nib load time to the object that loaded the nib (I don't know what object loaded my nib, so that does not help me). You should know that. Either it's the MainMenu.nib, which is automatically loaded by the application object (an instance of NSApplication, by default) or you've made explicit other arrangements. If you've got a nib other than MainMenu.nib, how are you arranging for it to be loaded? Whatever the answer to that question, it tells you what object will be the File's Owner. In MainMenu.nib, this is the application instance, which is a shared singleton instance of NSApplication (how all applications can share this is beyond me), It's not a singleton across all processes. That's not the meaning of singleton. A singleton is usually singular only in the context of a single process. Basically, the process which is your running application contains one single instance of NSApplication or an NSApplication-derived class. This object is the File's Owner of MainMenu.nib. which is also set to the global variable NSApp (uhh, OK...). A pointer to that object, the single instance of NSApplication or a subclass, is stored in a global variable, NSApp. (Again, just to avoid confusion, global within your process, not across all processes.) That's all well and good, but what exactly is this thing? Why would I succeed in having an outlet in my class if I set the Class Identity of File's Owner to my custom class? A nib is a collection of interrelated objects freeze-dried into a file. When you load a nib, you reconstitute the objects within it and reestablish the connections between them. However, this object graph would be disconnected from the other objects that already exist within your application, and so would have very restricted ability to interact with them. You want a way to connect up the two object graphs. So, in your design of your application, you pick some object that exists prior to the nib being loaded as the connection point -- the place where the new objects-to-be-loaded will connect up with your existing objects. Which of your objects you pick is up to you, although it is often convenient to use an instance of a custom subclass of NSWindowController or NSViewController. The nib has a placeholder in the freeze-dried object graph. This is like a blank spot on a diagram, where arrows point to it, but there's nothing there, yet. There can also be arrows pointing out from this blank spot to the other things in the diagram. When your code decides it's time to load the nib, you specify in that code that the object you picked in the previous paragraph will be the nib's owner. The nib loading machinery plops the owner object into the blank spot in the diagram. It already has existing connections to your object graph and now, as part of nib loading, the arrows to and from that blank spot are connected to and from that owner object. Objects in your nib which had references to the file's owner get references to that object. Where there were arrows pointing out from the blank spot, those are outlets from your file's owner. The nib loading machinery sets the outlets on your owner object to point to the newly-created objects from the nib. Now your object graph is integrated, where the new objects have the references to pre-existing objects which they need to access, and at least one of the pre-existing objects has a way of addressing the new objects. The nib needs to be told the class of your (future) file's owner so that it can know what outlets it supports. It figures this out by parsing the .h file which declares that class, looking for the IBOutlet keyword. You want to set up outlets so that the owner object has references to the objects that were created by loading the nib. Why should I set File's Owner's Class Identity rather than the Class Identity of a plain NSObject that I drag out of the Library in IB? Because that NSObject would not have any relationship to your pre- existing object graph. There are sometimes good reasons to drag an NSObject out of the library to instantiate it in the nib, and set its class to one of your own, and then hook it up to the other objects in your nib. It's just that this serves a different purpose than File's Owner. I hope that helps. Cheers, Ken ___
Re: File's Owner
On May 23, 2008, at 5:30 PM, [EMAIL PROTECTED] wrote: On May 23, 2008, at 2:49 PM, Johnny Lundy wrote: I decided to once again go verbatim through Cocoa Fundamentals. So far it has been largely uh-huh, yep, but the File's Owner, my nemesis, comes up again. [deleted] Again, I'm sensing a very fundamental disconnect, perhaps more fundamental than you realize. Anybody can recite documentation, so there's no need to tell us that and no need to recite the documentation. I think it would be more helpful to tell us at what *part* of the documentation you start to get lost, and what specifically is confusing about it, perhaps as relates to your other programming experience. The point at which after it says the proxy is filled in at runtime with the object that was set as the owner, so that the nib objects can communicate with other objects outside the nib*. What other objects outside the nib? I have nothing connected to File's Owner except the delegate, and looking at STOP. You just answered your own question. You connected the delegate outlet of an object outside the nib to some object within the nib. That is why File's owner exists! You just used File's Owner to make a connection to an object outside the nib. That object is the application's one and only NSApplication instance. File's Owner's off the shelf connections, the only one it has is to the About menu item. ...AND the delegate IBOutlet that you just said you connected. Don't forget that one. So I don't see why any object outside the nib could use File's Owner to find out about objects inside the nib, since File's Owner isn't connected to any objects inside the nib (except the About... menu item). The one and only NSApplication instance outside your nib found out about some object in your nib when you made a connection to File's Owner telling the NSApplication instance to set its delegate outlet to some object inside your nib. So I understand it's a proxy, I understand it has an object it knows as its owner, I know the standard owner is an instance of NSApplication aka NSApp global variable, but what I do not get is why I need this thing, or how it is needed to connect the rest of the nib objects with an object outside the nib. What object outside the nib? Maybe so that you can set the delegate of the NSApplication instance ? [lots of experience that indicates and ability to learn complex information deleted] But I don't understand File's Owner. Everything else that I listed up there, I understood. [deleted] Here's my problem. I didn't make any connections to File's Owner. I never have. Before bindings, I had a view object send an action to my class, by coding (IBAction) myMethod: in my code, and setting that action in the view object's action method. You mean except connecting the delegate outlet of the File's Owner. With bindings, I bind the view object to the NSArrayController, and the controller to an NSObject whose class is set to my custom class. Nothing done with File's Owner at all. In my opinion, you are not ready to use NSArrayController or bindings. [deleted] I understand that if I wanted to make another nib (which I definitely will need at some point), that I invoke loadNIbNamed:owner:, but I still wouldn't know why I was specifying an owner. I assume said owner would be an object, which might be one of my class instances, but really I have no idea. Well, let's see. If the NSApplication instance outside your MainMenu.nib had not been specified as the File's Owner for your nib, how would you have made a connection to the NSApplication instance's delegate outlet ? Please read http://lists.apple.com/archives/Cocoa-dev/2008//May/msg02323.html again. I despair that I am unable to adequately explain the concept and utility of File's Owner to you. This disturbs me greatly because I have written a book about Cocoa Programming, and I explained File's Owner in that book. I fear that I have failed. If I can't explain this concept to a very learned programmer, how can I explain it to a true novice. ___ 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]
Re: File's Owner
OK that's the first step towards saying what it is - the controller object that manages the corresponding user interface objects in the nib file. Now to find out what managing them means. This implies that NSApp is a controller object that manages the user interface objects in my nib file. I need to find out what NSApp is doing to my nib file objects to manage them. I'm getting closer. Thanks for the reference. On May 23, 2008, at 7:36 PM, Julien Jalon wrote: File's Owner can be any object in your application but is most often set to the controller object that manages the corresponding user interface objects in the nib file. ___ 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]
Re: File's Owner
...then it must be difficult. Actually, no. It is so much simpler and more elegant a solution than other frameworks that people have difficulty comprehending precisely because they keep trying to make it more complex than it is. 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. Yes, exactly: it will see all the properties of all the objects in the class that File's Owner is set to is what proxy means. What other objects outside the nib? That's up to you. Although the most general answer would be your application, but that's a bit too vague. The point is, a nib file by itself isn't worth much, at some point, somehow, the application has to be able to connect to it to gather data, for whatever purpose the application is intended. I'm going to take a guess here, that if the sense of the documentation were inverted, so that it said so that objects outside the nib can communicate with the nib objects, it might have made more sense to you. -- Scott Ribe [EMAIL PROTECTED] http://www.killerbytes.com/ (303) 722-0567 voice ___ 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]
Re: File's Owner
An example of multiple nibs where a nib's File's Owner wouldn't necessarily be NSApp would be System Preferences and the preferencepane bundles that it loads. NSApp would be SystemPreferences.app, and owns the main nib of the application. Each preference pane is an instance of NSPreferencePane (or a subclass), which is the owner of a nib that provides the user interface that loads in when you select the pane. So in that case, NSApp owns a nib, but also has a collection of NSPreferencePane objects, each of which owns a nib. Conceivably, an NSPreferencePane object might be paired with one or more other classes (for example, a class to load and display screen saver previews) which might want access to the pane's user interface widgets or their data. It would access those indirectly through the preference pane, which is connected to the widgets using the File's Owner proxy. On May 23, 2008, at 10:31 PM, Johnny Lundy wrote: OK that's the first step towards saying what it is - the controller object that manages the corresponding user interface objects in the nib file. Now to find out what managing them means. This implies that NSApp is a controller object that manages the user interface objects in my nib file. I need to find out what NSApp is doing to my nib file objects to manage them. I'm getting closer. Thanks for the reference. On May 23, 2008, at 7:36 PM, Julien Jalon wrote: File's Owner can be any object in your application but is most often set to the controller object that manages the corresponding user interface objects in the nib file. ___ 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/jonhendry%40mac.com This email sent to [EMAIL PROTECTED] ___ 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]
