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: Dragan Milić <email@hidden>
- Date: Tue, 10 Mar 2015 10:45:57 +0100
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