On Jan 17, 2013, at 4:19 PM, Andy Lee wrote: > On Jan 17, 2013, at 4:45 PM, Andy Lee <ag...@mac.com> wrote: > >> On Jan 17, 2013, at 2:53 PM, Ken Thomases <k...@codeweavers.com> wrote: >> >>> On Jan 16, 2013, at 2:47 PM, Melvin Walker wrote: >>> >>>> Is it possible to programmatically change color (using -setColor:) in >>>> NSColorPanel without it sending a changeColor: message to the first >>>> responder? >>>> >>>> We'd like it to just reflect a color change without telling the responder >>>> chain about it. >>> >>> I believe that NSColorPanel dispatches the -changeColor: action method >>> using -[NSApplication sendAction:to:from:]. Therefore, you should be able >>> to use a custom application object (subclass of NSApplication) with an >>> override of that method which short-circuits for that selector (perhaps >>> only under certain circumstances). >> >> Ooh! I tried overriding targetForAction:to:from: and targetForAction:, >> assuming they were getting called. But I didn't think to try >> sendAction:to:from:. Will give that a shot. > > Didn't work. > >> Note that even if this works, it doesn't suppress the >> NSColorPanelColorDidChangeNotification, so there may still be unwanted side >> effects of setting the color panel's color. > > NSColorWell doesn't implement changeColor:, yet when a color well is first > responder it changes to match the color panel. > > I tried a subclass of NSColorWell that implements changeColor: as a no-op. > The method got called, but the color well changed color anyway. > > So at least for color wells, changeColor: isn't the mechanism causing them to > change color when you set the color panel's color. I would think they must be > listening for the notification -- but I tried telling the color well to stop > observing that notification and it *still* changed color.
There are two issues here. One is whether -changeColor: is the method that's invoked to effect a color change when a different color is selected in a color panel. The other is how that method is invoked (whether by -[NSApplication sendAction:to:from:]). There's also a confounding factor that NSColorWell and NSColorPanel may be intimately connected in a way that other classes are not. As I understood it, Melvin was concerned that an arbitrary text view was having its color changed. It seems like quite a different scenario than the color in the color well that invoked the color panel. The color well may indeed have intimate knowledge about the color panel or vice-versa, but I doubt there's any non-generic mechanism by which the text view's color was changed. If there were, it would have to be documented so that one's own view classes (including custom text view subclasses) could participate. For one thing, it's apparently a known solution to implement -changeColor: in various subclasses to disable it. So, that answers the question of whether (for things other than color wells) the change goes through -changeColor:. Your experiments seems to indicate that that's not the case for NSColorWell, but it seems to be the case for other responders. It remains to be seen if the invocation of -changeColor: is dispatched via -sendAction:to:from:. I actually looked at the disassembly of the AppKit (on Snow Leopard) to see that it does, although it's always possible I missed something. One could put a breakpoint on -[NSTextView changeColor:] and look at the backtrace to see. Again, on Snow Leopard this technique shows it's called from -sendAction:to:from:. Regards, Ken _______________________________________________ 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
