Re: More PDFView mysteries...
Re: More PDFView mysteries...
- Subject: Re: More PDFView mysteries...
- From: Kyle Sluder <email@hidden>
- Date: Thu, 14 Jun 2012 19:21:03 -0700
On Jun 14, 2012, at 5:08 PM, Graham Cox <email@hidden> wrote:
>
> On 15/06/2012, at 8:15 AM, Matthew Weinstein wrote:
>
>> It almost feels like the windowControllerDidLoadNib is happening too quickly (or something).
>
>
> Note what that method literally tells you - the window controller loaded the nib. That doesn't mean that the actual window was instantiated yet (with all its views). A window controller lazily loads the window when it is actually required, which is a bit later. You can use the controller's windowDidLoad method to find out when that has happened.
You seem to be attributing more magic to NSWindowController than it actually possesses.
NSWindowController loads and instantiates its nib in response to -window being called while self.window==nil. After it has instantiated the nib (which is synonymous with "loading" it), it invokes -windowControllerDidLoadNib.
In other words, the window has indeed been unarchived from nib and assigned to the window controller's window outlet by the time -windowControllerDidLoadNib is invoked.
>
> The probable reason this is different on Lion is because NSDocument is a very different beast on Lion. It is often invoked on a background thread and various interface-less document objects are made to support Versions and Autosaving. It's a rather complex situation on Lion which *appears* to assume a very great deal about how your app has subclassed NSDocument. For example, when browsing Versions, each version you see is an actual instance of your NSDocument subclass complete with its window - it's not just the snapshot image you might have thought. Scary stuff.
This is true, but -makeWindowControllers is still invoked on the main thread, and obviously can only be called after your document has been instantiated (but possibly before the background read operation has signaled succes or failure; I can't recall if any guarantees are made about that).
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden