Re: All buttons lost focus ring on Yosemite
Re: All buttons lost focus ring on Yosemite
- Subject: Re: All buttons lost focus ring on Yosemite
- From: Chris Cianflone <email@hidden>
- Date: Thu, 12 Mar 2015 13:15:50 -0500
Hi all,
We had a similar issue. When running on Yosemite the same thing would
happen to us with the focus rings not displaying. Don't know if this helps
in your case, but the "fix" for us was to stop building with the 10.7 SDK.
Moving to the 10.8 SDK fixed the problem for us. (Don't ask why we are
using such old SDKs, and only moved to 10.8 instead of 10.9 or 10.10,
that's another story for another time.) You can see this in a simple Cocoa
app too started from an Xcode template.
Thanks,
Chris
_________________
Chris Cianflone
www.makemusic.com
On Tue, Mar 10, 2015 at 5:13 AM, <email@hidden> wrote:
> What happens if you turn on full keyboard access?
>
> Sent from my iPhone
>
> > On 2015/03/10, at 18:45, Dragan Milić <email@hidden> wrote:
> >
> > My previous message sent to the list apparently didn’t get admin
> approval, there were two attached images showing standard alarm panels with
> buttons which don’t draw their focus ring. Therefore, in this message I’ll
> combine answers to both Kyle and Graham.
> >
> >> On pon 09.03.2015., at 17.48, Kyle Sluder wrote:
> >>
> >> I'd start by looking at that -[NSView(NTExtensions) drawFocusRing]
> method. If you comment it out, what happens?
> >
> > No changes :-( I even went that far to remove the category completely
> and ignore all compiler warnings where added methods were used. Now, that
> would normally throw exceptions, but before even loading any application
> window and using any view requiring added category methods, the application
> shows two alert panels (one by one, attached images of those panels is the
> reason my previous message didn’t get through ), depending on current user
> preferences. That enables me to see buttons' behaviour even before any
> exception is thrown. Here is the link to the image of the first alert panel:
> >
> > http://media.cocoatech.com/first_alert.png
> >
> > What’s interesting here is that, as you can see, the alert’s
> suppressionButton checkbox DOES draw its focus ring, but other two buttons
> don’t! Believe my words, if I use tab/shift+tabs to change focus on them,
> they are focused (I can then activate them with the space), but the focus
> ring is not drawn, only the checkbox gets it correctly.
> >
> > Immediately after that first alert is dismissed, the second one appears,
> here is the link:
> >
> > http://media.cocoatech.com/second_alert.png
> >
> > With this one, even the focused suppressionButton checkbox doesn’t draw
> its focus ring. Other two buttons don’t too. And all this is with the
> NSView category completely removed. There are other NSView or NSControl or
> NSButton or NSButtonCell categories defined. The code defining both alarm
> panels is pretty standard, I can post it if necessary.
> >
> > Everything worked well in Mavericks, I’ve got no idea what happened in
> the meanwhile.
> >
> >> For safety, you really ought to be prefixing all of your category
> methods with some unique-to-you prefix.
> >
> > Yeah. As I’ve mentioned already, this is not my code, it was first
> created back in 2002 and until this problem I haven’t even looked into it.
> >
> >
> >> On uto 10.03.2015., at 00.44, Graham Cox wrote:
> >>
> >> In Xcode, add OBJC_PRINT_REPLACED_METHODS (value: YES) to your scheme's
> environment variables. Then all of the methods replaced by categories are
> logged when your app launches. While the list can be long and might take
> some time to go through, it will show you if any of your category methods
> are replacing anything - it's a much more reliable way to check than doing
> a class dump.
> >
> > Thanks for the suggestion Graham, I’ll do that. It’s be interesting to
> see if and what methods are replaced, although I don’t think it’ll solve
> this particular problem. I mentioned above it still happens even with the
> NSView category completely removed.
> >
> >> If you're not using those category methods, remove them. Most of them
> seem to be convenience methods that are possible "nice to haves" rather
> than vital to use NSView. Some appear to me to wholly misunderstand how a
> view stack (involving semi-transparancy for example) is actually drawn.
> Others are things that could be useful in particular circumstances but you
> probably wouldn't want to apply to every view your app ever instantiates
> including framework ones. For those custom views of yours that use these
> things, relocate that code to the custom view. It may mean a small
> duplication of code across a few different views, but it will be a lot
> safer than swapping out NSView wholesale. NSView just may be Cocoa's single
> most complicated class (any other contenders?). As a result, you probably
> can't foresee all possible effects of adding a category on it.
> >
> > As mentioned above, I’ve never looked into that code before this problem
> started. Now that I do, I’ll definitely do something about it and apply
> your suggestions.
> >
> > -- Dragan
> >
> > _______________________________________________
> >
> > 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
>
> _______________________________________________
>
> 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
>
_______________________________________________
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