On Oct 29, 2014, at 10:26 , Steve Mills <sjmi...@mac.com> wrote: > > As I said in my first message, I'm trying to *prevent* this behavior on the > entire window for all subviews withOUT having to subclass every conceivable > class that I might add to my window.
You can’t, because it’s not window behavior but rather view behavior (in spite of the way the documentation is worded) and the default NSView behavior *is* what you want/expect. What’s changed over the years is that particular NSView subclasses (especially NSButton, but probably some other controls too) have changed to return YES from “acceptsFirstMouse:’. To “fix” this, you don’t have to subclass every conceivable class. You can subclass NSButton and perhaps a few other controls that you might care about. However, this is the wrong solution. A button that doesn’t click through should *look* different when the app is in the background (and shouldn’t do rollover highlighting). So a better solution is to disable buttons you don’t want click-through for, when your app enters the background. Note that you don’t have to do this via code. If you provide a suitable property on (say) your app delegate, you can control the button enable state through a binding, so it’s no more onerous than hooking up action methods. > 1. Only rarely do I find it expected and useful. Otherwise, it's not good > user experience. You’re generalizing based on … personal preference? > 2. It forces you to aim at empty spaces if you simply want to bring a window > forward without inadvertently clicking something, so it slows you down. Converse: having the buttons be unclickable in the background forces you to click twice if you want to click something you can see, so it slows you down. > 3. It can be dangerous if you forget that an app exhibits this behavior and > you accidentally click a control in the background when you simple wanted to > activate the window, and that control deletes something, changes something, > or otherwise messes stuff up. Dangerous things should be undoable or have a confirming alert anyway. _______________________________________________ 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
