I'm currently running into a problem where active NSColorWells
conflict with my first responder's "changeColor:" method (i.e., if
there is an active color well, both it and my first responder change
colors).
The general solution I've seen on the archives is "check to see if
your color well is active, and if so, don't do anything in
changeColor:".
The problem is that I've got a bunch of dynamically loaded UI,
potentially with color wells in them, so there's no easy way to hard
wire in all the possible color wells (plus things like the font panel
include their own color well like objects for things like "background
color")
Two possible solutions that I've come up with are:
1) Walking all the various floating windows and the front document
window and recursing through all the subviews to see if there is an
active color well in any of them (which seems a bit burdensome)
2) Subclassing NSColorWell to force it to become the first responder
when it becomes active (which has the problem that inspector style
palettes can be hidden when the view isn't the first responder, and
said palettes are what hold the color well).
If there were some way to find everything that's listening to the
NSColorPanelColorDidChangeNotification I might be able to quickly
tell if there are active NSColorWells, but there isn't a documented
way to find all the listeners for a given notification.
Both 1 & 2 also (potentially) fail to handle things like the
"background color" attribute in the font panel.
Any other ideas on how to tell if "changeColor:" really means "you
should change color" as opposed to "somebody else should change
color, and you're just caught in the crossfire"?
