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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to