Xcode 10, Swift 4.2, macOS 10.13.
I have two text fields in my preference controller. Their purpose is to allow users to set a preferred default text style, which I will use elsewhere in my application. (This can be handled much more smoothly, but I have other problems to work out, and right now, working beats elegant.)

What I expected to happen: the colorWells are linked to setting the colour of the textField next to them, so that I select a colour for the top field (linked to the colorWell’s action), and whatever I type next is that colour.
What happens: Any time NSColorPanel.shared() is opened, any selected text – ANY selected text – takes on that colour.
If I change attributes through the fontPanel, the behaviour is as expected – the font panel takes the colour value FROM the text – but this is unwanted and unexpected. (I’d wondered about two colourWells for foreground and background colour… I now wonder how to implement THAT without messing things up…)
Ed. to add
This, apparently, is a feature. The Color Programming Guide says:
When you select a color in the panel, NSColorPanel sends a changeColor: message to the first responder. It also sends its action message (set by setAction:) to its target object (set by setTarget:), provided that neither the action nor the target is nil. NSColorPanel also sends its action to its target whenever you select a color in the color panel.
There seems to be no way to turn off this ‘feature’, and messing with firstResponder also doesn’t look like a useful thing to do. I have resolved this issue by supplying a single colour well (which now changes the colour of the active text). I still haven’t worked out how people implement ‘foreground/background’ colour well pairs.
Jan 29 2019
NSColorWell/NSTextField Bug
Xcode 10, Swift 4.2, macOS 10.13.
I have two text fields in my preference controller. Their purpose is to allow users to set a preferred default text style, which I will use elsewhere in my application. (This can be handled much more smoothly, but I have other problems to work out, and right now, working beats elegant.)
What I expected to happen: the colorWells are linked to setting the colour of the textField next to them, so that I select a colour for the top field (linked to the colorWell’s action), and whatever I type next is that colour.
What happens: Any time NSColorPanel.shared() is opened, any selected text – ANY selected text – takes on that colour.
If I change attributes through the fontPanel, the behaviour is as expected – the font panel takes the colour value FROM the text – but this is unwanted and unexpected. (I’d wondered about two colourWells for foreground and background colour… I now wonder how to implement THAT without messing things up…)
Ed. to add
This, apparently, is a feature. The Color Programming Guide says:
There seems to be no way to turn off this ‘feature’, and messing with firstResponder also doesn’t look like a useful thing to do. I have resolved this issue by supplying a single colour well (which now changes the colour of the active text). I still haven’t worked out how people implement ‘foreground/background’ colour well pairs.
By Extelligent Cocoa • Bug Reports, Interface • • Tags: NSColorWell