On 18/01/2013, at 9:19 AM, Andy Lee <ag...@mac.com> 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 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. 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. --Graham _______________________________________________ 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
