Re: earliest code that runs?
Re: earliest code that runs?
- Subject: Re: earliest code that runs?
- From: "Louis C. Sacha" <email@hidden>
- Date: Thu, 29 Jul 2004 15:53:09 -0700
Hello...
The problem you are having is part of the reason why it is desirable
to use multiple nib files per application and not cram everything in
the main nib file.
Within any particular nib file, the order that the items are
instantiated is not guaranteed [1], so when you have windows or other
interface items in the main nib file there is no way to ensure that
the core components of your application are correctly initalized
before anything else attempts to use them.
It is generally a good thing to keep only the core components of your
application in the main nib file, for example things like shared
objects that you want to use instances of a custom class for (the
shared document controller [2]), the application delegate, and the
main menu. Placing only these objects in the main nib file insures
that they are all initialized and set up correctly before any other
code (including freeze-dried nib objects, bindings, etc) tries to use
them.
Then, in the applicationWillFinishLaunching: or
applicationDidFinishLaunching: methods in your application delegate,
you would have the window controller(s) for your main window and the
rest of the interface load the appropriate nib files for everything
else.
This makes the overall design of the application a bit more
complicated for simple applications, compared to the common
"everything in one nib" approach, but it does also provide
significant benefits. In larger applications this kind of separation
is (IMHO) essential, and doesn't represent much additional work or
complexity.
Hope that helps,
Louis
[1]
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Protocols/NSNibAwaking.html#//apple_ref/doc/uid/20000425/BABGDAEF
[2]
http://developer.apple.com/documentation/Cocoa/Conceptual/Documents/Tasks/SubclassController.html#//apple_ref/doc/uid/20000953
...
>In that case you might be able to use applicationWillFinishLaunching:
Nope, not early enough. :)
What I was looking for was code that is guaranteed to run before the
initWithFrame: of this widget, yet is not in the class for this widget but
rather in some more general, controller-like location. So far, main() as
recommended by bbum is the only place I've found for that, and that's fine
with me.
The docs on binding to user defaults seem to imply that the app delegate's
+initialize will run before any instance methods:
...
If so, that must be an urban legend. Anyhow, one of the things I like about
science is that one counterexample suffices to disprove the hypothesis. My
app is a counterexample. m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
_______________________________________________
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.