Re: Details and the concepts related to the Nib Window
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? I presume he means via a breakpoint in the debugger. Typically people put a breakpoint in init and don't see it being hit because init isn't called, initWithCoder is what is used when unarchiving objects from a nib, but that's a tough one to break in. Typically, the first place your Interface Builder objects/delegates get called is awakeFromNib. That's the place to put a breakpoint where you can see the things you created in Interface Builder. Jon ___ 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: Details and the concepts related to the Nib Window
Also what does FilesOwner and First responder refers to. File's owner as the name suggests is the owner of the file, for example if your nib file is a window controller, the file's owner would be an object of class NSWindowController or your custom subclass of NSWindowController. 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. Implement the method awakeFromNib in any of the subclassed objects in your nib file, this method is called for each object in the nib file whenever the nib file is loaded, generally don't rely on the init method of these objects Also, when NSApplicationMain function is called from main.m file, what are the background stuff happening in the background. You may have to look up on NSRunLoop in the Threading Programming Guide I want to see these stuff so that I can modify things accordingly whenever needed. Thanks, Chaitanya Pandit Chief Architect Expersis Software Inc. On Mar 23, 2010, at 3:37 AM, Abhinav Tyagi wrote:___ 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: Details and the concepts related to the Nib Window
Jon Pugh mailto:jonp...@frostbitefalls.com wrote (Monday, March 22, 2010 11:22 PM -0700): I presume he means via a breakpoint in the debugger. Typically people put a breakpoint in init and don't see it being hit because init isn't called, initWithCoder is what is used when unarchiving objects from a nib, but that's a tough one to break in. Just for completeness: o Generally, objects that IB understands (i.e. the objects in the Library) are instantiated using -initWithCoder:. This is how IB initializes the object with the properties that you've defined in IB. o Custom subclasses of NSObject are instantiated with -init (this is so you don't have to make an object conform to NSCoding to use it in IB). o Custom subclasses of NSView are instantiated with -initWithFrame: (to be consistent with NSView's designated constructor, and also to avoid the NSCoding requirement). Typically, the first place your Interface Builder objects/delegates get called is awakeFromNib. That's the place to put a breakpoint where you can see the things you created in Interface Builder. Agreed! -- James Bucanek ___ 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
Details and the concepts related to the Nib Window
Hi, Thanks for your time for reviewing this. I am new to objective c and Cocoa on iMac OSX Leopard XCode3.1. 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. Also what does FilesOwner and First responder refers to. Also, when NSApplicationMain function is called from main.m file, what are the background stuff happening in the background. I want to see these stuff so that I can modify things accordingly whenever needed. Abhinav ___ 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: Details and the concepts related to the Nib Window
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 (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
