Re: PDFView drawPage called often after selecting text
Re: PDFView drawPage called often after selecting text
- Subject: Re: PDFView drawPage called often after selecting text
- From: Martin Hewitson <email@hidden>
- Date: Tue, 08 Jan 2013 07:02:47 +0100
On Jan 7, 2013, at 09:07 PM, Andy Lee <email@hidden> wrote:
> On Jan 7, 2013, at 2:10 AM, Martin Hewitson <email@hidden> wrote:
>> I've also checked that -setNeedsDisplay: is not being called on the PDFView.
>
> Could it be that setNeedsDisplay: isn't called but setNeedsDisplayInRect: is?
>
> On Jan 7, 2013, at 2:48 AM, Martin Hewitson <email@hidden> wrote:
>> Actually, at the risk of having a conversation with myself, I've narrowed the issue down to the actions I'm taking within my override of -drawPage:. Essentially what I'm aiming at is having a focus ring on the PDFView. I do this in my PDFView subclass:
>>
>> - (void)drawPage:(PDFPage *)page {
>> [super drawPage:page];
>> // focussed?
>> if ([[self window] firstResponder] == self && [NSApp isActive]) {
>> [[self superview] lockFocus];
>> NSRect fr = [self frame];
>> NSSetFocusRingStyle(NSFocusRingOnly);
>> [[NSBezierPath bezierPathWithRect:fr] fill];
>> [[self superview] unlockFocus];
>> }
>> }
>
> I'm not hugely familiar with PDFKit, so this may be a naive question, and it definitely delves into wild speculation...
>
> Why do you override drawPage: rather than drawRect:? I wonder if drawPage: is being called on multiple instances of PDFPage. Maybe (and here's the wild speculation) something about selecting text in the PDFView causes lots of PDFPage instances to be created, which would explain why you don't see the many calls to drawPage: until then.
>
> What do you see if you add NSLog(@"%@", page) to your drawPage: method? Is it the same PDFPage every time?
When it goes into overdrive, it's the same page every time.
>
>> - (BOOL)becomeFirstResponder {
>> [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
>> return [super becomeFirstResponder];
>> }
>>
>> - (BOOL)resignFirstResponder {
>> [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
>> return [super resignFirstResponder];
>> }
>
> Not sure if this relates to your problem, but it seems to me you should test the results of super first. For example:
>
> - (BOOL)becomeFirstResponder {
> BOOL didBecome = [super becomeFirstResponder];
>
> if (didBecome) {
> [self setKeyboardFocusRingNeedsDisplayInRect:[self bounds]];
> }
>
> return didBecome;
> }
>
> And similarly for resignFirstResponder.
Yes, that's right. But doesn't help the problem, unfortunately. The PDFView is not the first responder when I'm typing, so the 'fault' is triggered when the PDFView first becomes first responder then the NSSetFocusRingStyle part of the code is called. The fault then persists.
>
> Also, I would be curious how often these get called -- I don't suppose they're getting called with every key you type into the text view? It does seem weird that drawPage: is getting called when you aren't even interacting with the PDFView.
It's called about every 200ms, so I don't think it's for every keystroke, but it's hard to tell.
> I don't suppose your text view has a delegate that is doing something that might affect the PDFView?
Not that I can find, but I'll look again. The text view has a delegate and does a lot of stuff, but I couldn't find any interaction with the PDFView so far.
Thanks for your thoughts!
Martin
>
> --Andy
>
_______________________________________________
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