• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Load order of nib internals
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Load order of nib internals


  • Subject: Re: Load order of nib internals
  • From: Shaun Wexler <email@hidden>
  • Date: Tue, 16 Sep 2003 05:10:45 -0700

On Sep 15, 2003, at 10:22 PM, Scott Anguish wrote:

On Sep 15, 2003, at 11:16 PM, Francisco Tolmasky wrote:

Alright, I have two instantiated objects within my nib, an application controller and a custom document controller (so that it becomes the default document controller). Currently, the document controller is being loaded first, which crashes my program because it relies on some things set up in the +initialize phase of my application controller. Is there anyway to change the load order to avoid this?

Unfortunately, +initialize has no guarantee on the order for loading, so you need to find a different way to accomplish this.

The order in which the classes appear in the app's source target build style in PB/Xcode will determine their relative position within the object/executable file. The NSPrincipalClass will be loaded first, and +load will be called on that class. Any classes you reference in that method will receive +initialize before anything in them will be called, which might cause +initialize to be called before +load, as well as prior to calling main(). If both objects are instantiated by the main nib, that happens before the NSApp's run loop is started, which is after NSApplication receives +load, +initialize, and +sharedApplication. You shoud consider moving your nib objects' +initialize code into -awakeFromNib instead, which is what is intended for. The NSDocumentController subclass wouldn't normally be instantiated until the run loop is entered, during NSApp -finishLaunching, so in this case, even your subclasses -awakeFromNib methods are called before that would happen. Move your NSDocumentController's dependent code into -awakeFromNib or -init (which is called by +sharedDocumentController, after you receive NSApplicationWillFinishLaunching). FYI, for singleton classes such as that, you typically shouldn't try to utilize class methods, other than for retrieving the shared instance. Here is the "standard" load order, I believe:

NSApplication +load
other classes +load (and/or +initialize methods, depending on their references *)
main()
NSApplication +initialize *
NSApplication +sharedInstance (instantiates singleton via alloc-init)
...
NSBundle +loadNibNamed:owner:
... instantiates objects, whose classes receive +initialize and/or +load *
NSApp -run
NSApp -finishLaunching (here is where NSDocumentController is instantiated)

Hope that helps.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Load order of nib internals (From: Francisco Tolmasky <email@hidden>)
 >Re: Load order of nib internals (From: Scott Anguish <email@hidden>)

  • Prev by Date: Loading and resaving PDF files as PDF
  • Next by Date: Re: Creating directories if they don't exist
  • Previous by thread: Re: Load order of nib internals
  • Next by thread: Re: Load order of nib internals
  • Index(es):
    • Date
    • Thread