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
