Strange: I can use it, but it makes no difference if I select it before. The target icon can be moved and set anyway.
But when I have clicked on it and select “OK”, the magnification lens that should have been visible while picking a color appears then until I click somewhere else again.
So I just tested it in Shine, which uses a NSColorWell and so far everything seems to work as expected. If needs be, I can potentially rip out my NSColorWell and post it. It may take me a few days as I’m working towards a deadline.
The following code uses the NSControl from the MacOSLib, I’ve just added a subclass of it to handle the NSColorWell (which solved a lot of issues in our apps).
Thanks Sam.
I have a question though: Your example has an NSColorWell Control on the window, which needs to be clicked in order to present the color wheel window. How do I modify it, so that a normal toolbar button causes the color wheel window to open?
I’ve been trying to replicate SelectColor with declares but showing the NSColorPanel with runModalForWindow or beginModalSessionForWindow has the same pipet bug. Maybe this isn’t supposed to be used modally anymore, or I’m not doing the modal properly which is very possible.
The SelectColor pipet does work in Carbon apps. Also SelectColor shows Cancel and OK buttons which I’ve read come with using the Carbon functions PickColor and NPickColor. Not sure how else to add those buttons.
Anyways, I like the continuous feed of non-modal so gave up replicating SelectColor. Instead, for those situations where there is no widget/ColorWell I made an interface that receives color changes and a class to show and hide the NSColorPanel singleton. This is a first draft, unfinished, bugs?. please feel free to modify, fix, refactor. Maybe Sam has another elegant solution like NSColorWell.
Thats the kicker, I used a custom control in the past and tried to wedgie it into the NSColorPanel, what I found was that’s possible to have more than one delegate, so changing the color in the TextArea (which it links to it automatically if the user clicks into a TextArea) would also change the color within my custom control.
The only way I found to use the NSColorPanel and have it behave correctly was to use a NSColorWell. You can attach a NSColorWell to the toolbar, if you see the last edition of the xDev magazine I included an article on Yosemite tricks, one of these is to move standard controls to the toolbar so that they show up in the window titlebar.
Maybe @Joe Ranieri can shed some light on how Xojo does it and we can figure out something from there.
Don’t be surprised if this is a bug in Yosemite, there’s more than plenty in this release. It seems Apple is rushing it’s software nowadays and that’s a bad place for Apple to be in!
I’m posting a slightly altered version of my internal notes from the case requesting alpha channels be added to SelectColor.
[quote]Xoxo calls the legacy GetColor function, which is modal and operates in RGBColors. Unfortunately this means it has no alpha channel support.
NSColorPicker does have a public API for setting an accessory view and can be ran modal. To get the titlebar appearance as shown in the Carbon picker, various aspects of the panel were tweaked, which is most likely not allowed. Also, when using the accessory view, the buttons are not added at the bottom of the panel, but slightly above the row of ‘favorite’ colors.
NSColorPicker also has the unfortunate behavior in that it sends the changeColor: message to the window’s first responder. This means that even when the picker is running modal, colors in other parts of the program can change.
Needless to say, this yielded less than satisfactory results.[/quote]