On 10 Dec 2013, at 22:26, Jens Alfke <j...@mooseyard.com> wrote: > On Dec 10, 2013, at 1:07 PM, Pax <45rpmli...@googlemail.com> wrote: >> Ah! Exactly right. It is nil - but surely I shouldn't have to initialise >> it? I never have in the past - I built the UI with IB, and I was under the >> impression that that would handle all the initialisation for me. > > The code must be running before the nib’s been loaded. Set a breakpoint and > look at the backtrace for clues. > > You mentioned awakeFromNib being called twice — the situation I’ve seen this > happen is when an object is _contained_ in one nib, and also the _owner_ of > another (that it loads). For instance if your app delegate has a method that > loads a nib with itself as the owner, then -awakeFromNib will be called once > when the app initializes and MainMenu.nib is loaded, and then again when you > load your own nib. Different outlets are going to be hooked up at those times.
Another popular mistake is to have 2 objects instead of one. E.g. if you have an NSWindowController subclass that gets created by your app delegate, and in this NSWindowController’s XIB you have dragged out a second instance of the same subclass, and instead of hooking up the outlets of the File’s Owner, you’ve hooked them up to the second object. Then the File’s Owner gets created, loads its XIB, which creates the second subclass, which gets hooked up to the window. Then one of the two objects has all the UI objects, the other is the one you set properties on and so on. So have you checked whether ‘self’ is actually the same in both calls? A variant of this issue can happen with objects whose superclass implements NSCopying, but you forgot to implement -copyWithZone: in your subclass. Then sometimes you seem to get parts of your object initialized twice, when in fact you’re seeing a copy of your object being talked to. Mind you, NSPreferencePane doesn’t implement NSCopying, so I doubt this is the case here, at least not directly. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de _______________________________________________ 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
