On Dec 23, 2009, at 03:06:58, Gregory Weston wrote: > Did you happen to have an 'a-ha' moment when you typed that sentence? "Views" > don't generally have an active/inactive state. Controls, which are a special > case of view, do. So have you considered making your custom view an NSControl > instead of a simple NSView? > > That's the thing, you see. "Inactive" means the user can't interact with it. > But the user can't interact with a view that's not a control anyway, so the > state has no meaning.
On the contrary, users can interact with an inactive control. They can't interact with a disabled control. Consider a scroll bar. It can draw in an inactive state (not blue), but you can still interact with it by sending the window scroll events (something I'm unconvinced you should be able to do, but you can, and it proves convenient). In my case, it's a drawing canvas. However, the active drawing tool should not draw when the view is inactive (not frontmost). Since the tool is a singleton object in the app used by many views, it's important to be able to make the distinction. I suppose I could subclass NSControl, but this strikes me as inelegant (and I don't know that it has active/inactive state anyway). -- Rick _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
