On Jan 17, 2013, at 5:47 PM, Ken Thomases <k...@codeweavers.com> wrote:
> 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. No, it's the same scenario. I happened to use the color well to bring up the color panel, but that doesn't matter. What matters is that the color well was first responder on the key window at the time I called setColor: on the color panel, which I did via a pushbutton action. > 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. Both changeColor: and the notification are indeed triggered. I haven't tested target-action but I'm sure it works too. > For one thing, it's apparently a known solution to implement -changeColor: in > various subclasses to disable it. Oh, wow, sure, that would do 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, Yup. Also note the API makes no claim about what mechanism is used for any given control. It could be changeColor: today and notifications or some secret backdoor tomorrow. I can't think why it would change, but it's theoretically possible. > 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:. It is. I overrode sendAction:to:from: in my application subclass. > 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:. I would assume changeColor: is always sent to the first responder regardless of the class of the current first responder. It wouldn't make sense to first check what kind of object the first responder is, and send the message or not accordingly. Rather, let the responder chain sort it out. The mystery here (unless I messed up my tests) is how color wells get updated and why they should be different from other controls in this respect. --Andy _______________________________________________ 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
