Re: Changing color in NSColorPanel without message
Re: Changing color in NSColorPanel without message
- Subject: Re: Changing color in NSColorPanel without message
- From: Andy Lee <email@hidden>
- Date: Thu, 17 Jan 2013 19:13:38 -0500
On Jan 17, 2013, at 6:44 PM, Graham Cox <email@hidden> wrote:
>
> On 18/01/2013, at 9:19 AM, Andy Lee <email@hidden> wrote:
>
>> o 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.
>
>
> Coming late to this discussion and may not have anything relevant to add, but I have used these classes fairly extensively, including special custom subclasses.
>
> Colorwells have some sort of per-application non-public controller that allows only one to be active at a time - if you click on one, any other already selected no matter where it is in your interface will be deselected.
I never noticed that! And I just quickly confirmed it. Seems kind of rude that selecting a color well in one window can take first responder status away from a color well in a different window.
> I believe this controller (which may just be some private class methods) is also responsible for handling the interaction between the colorwell(s) and the color panel. This bypasses the public interfaces AND the notification. In other words, there is a private API that allows the color panel to know which colorwell is the active one and directly set its colour.
It sure behaves that way. Another possibility is that the mystery controller listens for the notification. This would mean the color panel sticks to its documented ways of updating other objects -- target-action, changeColor:, and notification -- and it's only the controller that has a backdoor relationship with NSColorWell.
> For the OP's case though, hacking around with this mechanism is probably unnecessary. To get some object to respond to -changeColor:, even if it's not in the responder chain, is easy as long as you can get some object that is in the responder chain (such as the view that is displaying them) to punt the call down to it, by retargeting the method, for example, or using invocation forwarding. I've used that approach extensively and it's pretty general - if you have objects that can be selected that are displayed in some view, you can get that view to be aware of the selected items and pass messages down to them as if they were part of the responder chain. It's a very generic and I think quite elegant approach. The selectable objects themselves can be written *as if* they were first-class responders and rely on some higher level controller or view to ensure they actually do receive the messages sent to FR.
The OP actually wants to *suppress* changing of color. But good to know.
--Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden