More PDFView mysteries...

  • Dear Cocoa-Devs,
    I have an app that works perfectly on snow leopard, it consists of a split view with a pdfview on top, and another view on the bottom. On lion however the pdfview is blank until I resize the window or splitview. I've tried throwing various things at the window in the windowControllerDidLoadNib: section [myPDFView display]... [myWindow setNeedsDisplay: YES]...

    It almost feels like the windowControllerDidLoadNib is happening too quickly (or something). BTW this splitview is in a tabview... If I manually tab to something else and back, it refreshes, if I do it programattically at the end of the ...didLoadNib: method, nothing, doesn't work.

    Ideas? Anyone else having pdfview lion problems.

    Matthew Weinstein
    Professor of Science Education
    Education Program
    U.W. - Tacoma
    253 692-4787

    <mattheww...>

    Campus Box: 358435
    1900 Commerce Street
    Tacoma, WA  98402-3100
    Office:  (253) 692-4787
    FAX:    (253) 692-5612
  • 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.

    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.

    --Graham
  • That is a problem; I think this is a pdfkit bug, and I need to register it (slowly figuring these things out). What I did to isolate the problem was create a project with a window in which I just dropped a pdfview and pdfthumbview on (didn't even bother to change the sizing. Hardcoded an URL to a pdf; created a PDFDocument init'd with the url and then did [mypdfview setDocument: myURL]. All of that in the windowcontrollerDidLoadNib method.

    same problem. pdfviews can't be set in the init'd in the windowControllerDidLoadNib; but I think the problem is bigger.

    I relocated the load code so it was activated by a button rather than the windowController: same problem. There's a definite pdfview problem...

    Solutions?

    On Jun 14, 2012, at 5:08 PM, Graham Cox 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.
    >
    > 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.
    >
    > --Graham
  • On Jun 14, 2012, at 5:08 PM, Graham Cox <graham.cox...> 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
  • Should also have noted: I believe this problem started with 10.7.4.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.elevated-dev.com/
    (303) 722-0567 voice
  • On Jun 15, 2012, at 7:19 AM, Scott Ribe wrote:

    > On Jun 14, 2012, at 3:15 PM, Matthew Weinstein wrote:
    >
    >> Ideas? Anyone else having pdfview lion problems.
    >
    > Yes, the problem you described, plus also fairly frequently crashes on closing the window--looks like invalidate being sent to a timer that no longer exists, when my window controller does not create any timers.
    >
    > Now Graham is right that you should be using awakeFromNib or windowDidLoad anyway, but that's not the problem in my case.
    >
    > --
    > Scott Ribe
    > <scott_ribe...>
    > http://www.elevated-dev.com/
    > (303) 722-0567 voice
    >
    >
    >
    >

    --
    Scott Ribe
    <scott_ribe...>
    http://www.elevated-dev.com/
    (303) 722-0567 voice
  • On 15 Jun 2012, at 16:20, Scott Ribe wrote:

    >>> Ideas? Anyone else having pdfview lion problems.
    >>
    >> Yes, the problem you described, plus also fairly frequently crashes on closing the window--looks like invalidate being sent to a timer that no longer exists, when my window controller does not create any timers.

    Indeed, the only way I found to solve this is to build in 10.7.3, but according to my tests the issue only happens when you've attached a PDFThumbnailView to the PDFView. I believe otherwise the crash on close doesn't happen.

    >> Now Graham is right that you should be using awakeFromNib or windowDidLoad anyway, but that's not the problem in my case.

    I don't believe that will solve the issue of the blank PDFView. If you _must_ build on 10.7.4 you could end the awakeFromNib or windowDidLoad with:
    dispatch_async(dispatch_get_main_queue(), ^{
      [self setNeedsDisplay:YES];
    });

    A hack, but it should cause the PDFView to display its contents.

    -António

    -----------------------------------------------------------
    And you would accept the seasons of your
    heart, even as you have always accepted
    the seasons that pass over your field.

    --Kahlil Gibran
    -----------------------------------------------------------
  • On Jun 15, 2012, at 7:48 AM, Antonio Nunes wrote:

    > Indeed, the only way I found to solve this is to build in 10.7.3, but according to my tests the issue only happens when you've attached a PDFThumbnailView to the PDFView. I believe otherwise the crash on close doesn't happen.

    I'm building on 10.6.8, and I do not use PDFThumbnailView.

    --
    Scott Ribe
    <scott_ribe...>
    http://www.elevated-dev.com/
    (303) 722-0567 voice
  • On 15 Jun 2012, at 16:58, Scott Ribe wrote:

    >> Indeed, the only way I found to solve this is to build in 10.7.3, but according to my tests the issue only happens when you've attached a PDFThumbnailView to the PDFView. I believe otherwise the crash on close doesn't happen.
    >
    > I'm building on 10.6.8, and I do not use PDFThumbnailView.

    Interesting, I never had this problem until I updated my system to 10.7.4. After being unable to work around the issue, I put 10.7.3 on a separate partition, and building there, with the same version of Xcode does not expose the crash.

    -António

    -----------------------------------------------
    Touch is a language without words
    -----------------------------------------------
previous month june 2012 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today