What happens if you turn on full keyboard access? Sent from my iPhone
> On 2015/03/10, at 18:45, Dragan Milić <mi...@mac.com> 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 (Cocoa-dev@lists.apple.com) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com > > This email sent to dangerwillrobinsondan...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
