Re: PDFKit: problem with PDFView goToDestination across PDFViews.
Re: PDFKit: problem with PDFView goToDestination across PDFViews.
- Subject: Re: PDFKit: problem with PDFView goToDestination across PDFViews.
- From: John Calhoun <email@hidden>
- Date: Mon, 11 Dec 2006 18:46:49 -0800
The good news, your code works as expected on Leopard. :-)
Okay, here is what I believe is going on in Tiger:
When you call -[PDFView goToDestination:] the PDFView is sort of still
in flux. It was just created, you are calling -[setFrame], etc. The
view hasn't "settled down" so to speak so some of the layout and view
management code is in an sort of undefined state. Don't ask — it is
the main reason the whole PDFView internals were re-written for
Leopard (and as I mentioned, it has paid off).
My best suggestion is to somehow delay the [PDFView goToDestination:]
call (and this will not break on Leopard). Either schedule the call,
hang it off the current run loop, fire off an NSTimer, etc. Whatever
makes sense to you and works. In short, let the PDFView finish it's
layout etc. before calling goToDestination. (This is why, BTW it
works for your already up and existing PDFView).
PDFView in TIger is doing some of its own scheduling and delaying —
you have to work around that.
john calhoun—
On Dec 11, 2006, at 3:37 PM, Michael McCracken wrote:
I was using the same PDFDocument object - I had one PDFDocument, two
controllers, and two PDFViews, both set to use the same document
object.
I'm still confused as to why it doesn't work as I wrote it in my
original email, but I also tried a version that avoids passing
PDFDestinations, and instead uses page indexes and NSPoints and
regenerates a PDFDestination in the secondary window controller:
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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