Re: Details and the concepts related to the Nib Window
Re: Details and the concepts related to the Nib Window
- Subject: Re: Details and the concepts related to the Nib Window
- From: Ken Thomases <email@hidden>
- Date: Tue, 23 Mar 2010 00:54:16 -0500
On Mar 22, 2010, at 5:07 PM, Abhinav Tyagi wrote:
> Whenever we drag an object from the Interface builder to our Nib window
> (like we do for a controller object), it means that we are instantiating the
> object of a class or interface. But where actually can i see it being
> instantiated.
What do you mean by "see"?
You are seeing it being instantiated right there in IB. Interface Builder does not build a set of instructions to later be played back. It builds an object graph which is archived in the NIB and later reconstituted.
> Also what does FilesOwner and First responder refers to.
File's Owner is a placeholder, a stand-in proxy, for an object which will be provided at NIB-loading time. Loading a NIB reconstitutes an object graph. However, the object graph created from the NIB would end up being largely isolated from the existing object graph in the rest of the program. By connecting the objects in the NIB to File's Owner, and vice versa, and then providing one of the objects from the pre-existing object graph to be the owner of the NIB, you can connect the two object graphs together in useful ways.
For the application's main NIB, the framework specifies that the application object will be the owner. Therefore, in the main NIB, the File's Owner and the NSApplication proxy are redundant with one another.
First Responder is a conceptual placeholder or proxy. It doesn't represent a particular object, it represents the responder chain. You should read about the responder chain in the Cocoa Event Handling Guide.
Basically, if you connect an action control to the First Responder, then when that control is manipulated by the user it will send its action to the responder chain instead of a pre-determined, fixed object.
> Also, when NSApplicationMain function is called from main.m file, what are
> the background stuff happening in the background.
This is documented most clearly in the class overview for NSApplication.
> I want to see these stuff so that I can modify things accordingly whenever
> needed.
Again, what do you mean by "see"? Also, it is very unusual for one to need to modify what happens during NSApplicationMain.
You can probably achieve what you need by setting up an application delegate and implementing the various NSApplication delegate methods on it. On rare occasions, you may find a need to subclass NSApplication, but you usually don't have to -- the delegate methods should be sufficient.
Regards,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden