Well the documentation for 10.6 does say that awakeFromNib is called
only if the receiver responds to it, I don't have the leopard docs on
my machine at the moment so I don't know what that says.
Are these new objects really new classes which weren't in the NIBs
before or are classes which were always in the NIB, but where you've
now changed the implementation of the class to use the new refactored
code? My thought was that the NIBs themselves might contain hints
about whether to call awakeFromNib compiled in and the NIBs themselves
were not recompiled as their content objects appear to be the same. If
that is possible, then touching some of them and forcing them to
recompile might sort it out.
On 25-Oct-2009, at 7:53 PM, Graham Cox wrote:
I have, or rather had, a problem. I've solved it but I'm still not
sure why the problem is there in the first place.
I have a bunch of controller classes which have a common base class,
and this in turn subclasses NSObject. Recently I factored out some
code into an even more primitive base class between NSObject and my
former base class so I could fork it in another direction. I
carefully tested on 10.6 and all was well. Lots of these controllers
are instantiated in various nibs.
Then, running on 10.5.(8) I stared to get an error that the object
<new class derived from new base class> did not respond to -
awakeFromNib. I'd not previously seen this error until I refactored
my code. Sure enough my new base class and its new fork don't
implement awakeFromNib because they don't need to. On 10.6 there is
no error. On 10.5.8 I get the error, suggesting that 10.6 first
checks whether -awakeFromNib is implemented and 10.5 does not.
Easy to fix - I added an empty awakeFromNib to the base class and
the problem is solved. What I don't understand is that I've never
previously been forced to add empty awakeFromNib methods to nib-
instantiated classes deriving from NSObject before and they've
always opened without a problem on 10.5 and earlier. So what's the
difference this time?
--Graham
_______________________________________________
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/rols%40rols.org
This email sent to r...@rols.org
_______________________________________________
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
