Hi,
Many thanks for your replies, much appreciated - they have helped me track and
solve the problem, so I’m very grateful.
My app does it this way and it has always worked without any special work
needed. I'm not sure what your problem is, but doing it this way works for
me, suggesting that the documentation is at least accurate.
Thanks Graham. Sorry if I was unclear - I wasn’t trying to suggest it was a
problem with the docs; I was just trying to clarify what I had tried.
It's important to make a distinction between +initialize (the class
method which is sent by the runtime the first time a class is sent a
message) and -init (the instance method used to initialize an object).
Yes, I was trying to find out which class got called first, but obviously
NSDocumentController would receive +initialize before its subclass no matter
what anyway, so NSLogging there wasn’t all that useful. As it turns out,
though, it was an +initialize problem with my app delegate (see below).
Can you set a symbolic breakpoint on 'sharedDocumentController' and simply
find out when and where it's first called?
*Coughs with embarrassment.* Well, yes, I could, but that would save me posting
questions I should have been able to solve myself. :) That was indeed exactly
what I needed to do, thank you. As soon as I set a breakpoint on
-[NSDocumentController sharedDocumentController], I saw that in the cases where
my subclass wasn’t getting loaded first, -sharedDocumentController was being
called by NSColorPanel, not by my code. This told me instantly what was wrong.
My app adds a custom colour list using NSColorPanel’s -attachColorList:, but I
had set this up in my application delegate’s +initialize method - I’ve no idea
why I had put it there (which should just initialise my default preference
values) rather than in -applicationDidFinishLaunching:, but I had, and that was
the problem. As my app delegate and document controller subclass are both
top-level objects in MainMenu.nib, there’s no guarantee which will be
instantiated first, which explains why I was seeing apparently random
behaviour: if my document controller subclass was instantiated first, then it
became the shared document controller and my templates panel worked fine; but
if my app delegate was instantiated first, then its +initialize method called
through to NSColorPanel, which in turn called through to
-sharedDocumentController, thus instantiating a standard NSDocumentController
before my custom subclass could be used. (This was further
obscured by the fact that NSColorPanel only calls on NSDocumentController if
it needs to restore a selection in one of its tables, because that will then
call down the responder chain to check if anything needs to change colour, I
believe.)
So, moving my colour list creation code to -applicationDidFinishLaunching:
(where it should have been in the first place) fixed it.
Many thanks again for the help,
All the best,
Keith
- Original Message
From: Kyle Sluder kyle.slu...@gmail.com
To: Keith Blount keithblo...@yahoo.com
Cc: cocoa-dev@lists.apple.com
Sent: Mon, March 8, 2010 1:10:14 AM
Subject: Re: NSDocumentController subclass not instantiated first?
On Sun, Mar 7, 2010 at 4:09 PM, Keith Blount keithblo...@yahoo.com wrote:
Running some test NSLogs, it certainly seems that NSDocumentController’s
-initialize method is called before that of my application delegate -
although I’m not entirely sure that is telling or not. I’ve been through my
code looking for calls to NSDocumentController, trying to find any calls that
could conceivably occur before MainMenu.nib gets initiated, but so far I’m
stumped.
It's important to make a distinction between +initialize (the class
method which is sent by the runtime the first time a class is sent a
message) and -init (the instance method used to initialize an object).
As Quincy says, set a breakpoint on -sharedDocumentController. If that
doesn't work, you could load your app up in Instruments and use the
Object Graph template to find out where the first NSDocumentController
instance is allocated.
--Kyle Sluder
___
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
