SelectColor issue on Yosemite

Sam_Rowlands · October 23, 2014, 2:40am

Thanks Joe, it looks like a dead end if trying to do this properly.

Richard_Summers · November 22, 2014, 9:22pm

Sam, regarding your last post, are you saying that your project still does not work properly, or did I misunderstand your last post?

Sam_Rowlands · November 23, 2014, 1:19am

IMHO, I’m not sure that it’s possible to show the color picker in a modal dialog correctly. Mind you, it seems that Apple is abandoning their OS wide color picker. iWork no longer uses it and I think a clown took a dump on it in Yosemite.

So perhaps it’s time to consider rolling our own, we can have blackjack and hookers…

Joe_Ranieri · November 23, 2014, 2:02am

There are a lot of things that NSColorPanel does and I don’t think attempting to replicate it is a great idea.

Sam_Rowlands · November 23, 2014, 3:39am

I understand that the NSColorPicker has a lot of options, but it seems like Apple doesn’t care about it any more (take a look at the newer Pages, Keynote), they don’t even use it any more, the crayon picker in Yosemite got hosed in appearance.

Richard_Summers · November 23, 2014, 5:22am

I just need a working color wheel and screen color pipette.

Will_Shank · November 23, 2014, 8:06am

Sams and my code works to do that, the problem is TextAreas will automatically interact with a displayed color panel.

If a TextArea has focus while you’re selecting a color for something else the text color gets updated too. And if the panel is showing when you click into a textArea the panels current color will be updated to the text color.

The solution I’ve read for the first part (preventing text color change) is to subclass NSTextView and override changeColor. I’ve tested this the bad way (swizzling changeColor on XOJTextView which is Xojos NSTextView subclass) and it works. The proper way I think in Xojo is to use an entirely declare built TextArea, ala MacOSLib.

The second part, preventing a TextArea from changing the panels current color, I haven’t figured out yet.

But just now I found out if you turn the TextAreas Styled property Off it doesn’t interact with the color panel. This TextArea-ColorPanel interaction is app wide so you’d need to turn Styled Off on all TextAreas in your app, even ones on windows other than where you call for the panel. Or possibly you can hide/dismiss the panel when showing a Styled TextArea. All depends on your app.

If you don’t need Styled you should be good to go. If Sams ColorWell can’t be used in a toolbar you can use my code which doesn’t need a UI widget.

Richard_Summers · November 23, 2014, 4:34pm

Will, I know this may sound silly, but could you not simply just remove focus from all the window’s controls in the action event, in order to prevent issue 1 from happening?

Sometimes people overthink things, when the absolute simplest solution solves the issue?

My idea is probably ridiculous, but that to me seems the most obvious solution in order to prevent any text areas with the focus from being changed.

Thanks.

KarenA · November 23, 2014, 5:01pm

A crazy idea idea for Xojo inc that is naively conceived and probably all wrong for some reason …

If the System Color picker won’t play nice WITHIN an Xojo app in 10.10 then make it a helper app distributed with the framework and only launched from it, that passes back the selected color value …

The color picker helper app would NOT be coded with Xojo so that it does not drag in the UI framework and so be small and very fast to launch.

Michel_Bujardet · November 23, 2014, 6:49pm

[quote=136403:@Oliver Osswald]On Yosemite I am no longer able to use the ColorPicker on the SelectColor window as before. It seems to be broken.

Can anyone confirm?

http://osswald.com/xojo/issues/SelectColor.xojo_binary_project.zip

Test on Yosemite:

Click Button “Select Color”
Click on the color picker pipet near the cancel button
Note: You cannot pick a color
Click Button OK
Note: The Colors Window is closing and now only the color picker appears

[/quote]

I just tried with 2014R2.1 as well as 2013R3.3, and in both cases I can pick a color in the rainbow circle under 10.10.1.

The strange bug is that after clicking OK, I get a 150 pixels or so circle at the cursor, and a blown up vision of the pixels.

As far as I can tell, the wheel works. A screen color pipette is an entirely different feature, doable by capturing the screen picture and picking the color on it within the app according to the position of the mouse.

[quote=145259:@Will Shank]The second part, preventing a TextArea from changing the panels current color, I haven’t figured out yet.

[/quote]

Can’t you just disable the TextArea just before calling the wheel, and re-enable it afterward ?

Richard_Summers · November 23, 2014, 8:18pm

I have already created my own screen color picker, but would rather use the default color wheel and color picker pipette if possible.

Michel_Bujardet · November 23, 2014, 8:43pm

From what I can see, the color pipette in the color wheel is not meant to pick colors on the screen, only within the wheel. I doubt any amount of declare can change that behavior, if it is the way Apple meant it to be.

You will have to create your own solution.

Will_Shank · November 23, 2014, 9:40pm

For the pipette to work the panel can’t be run modally. That’s not documented, just experience. Xojos SelectColor runs modally and works correctly except for the pipette and when I modify my declares to run the color panel modally the same thing happens.

But with declares it can be run synchronously and the pipette works, allowing picking of any color on screen with the magnifying glass while the panel is showing. So that’s the way I’m using it and while the color panel is up you can still click around anywhere in your app, if that’s on a Styled TextArea or you tab into it then the panel losses allegiance.

For my uses I rarely need a Styled TextArea so turning Styled off will work.

I tried closing the panel in a Styled TextAreas GotFocus and MouseDown events but the color still gets changed before the panel is closed. Trying to enable and disable the TextArea has it’s own problems. It looks like the panel doesn’t actually close until the next event loop so a Timer or some boolean switch would need to be setup that coordinates with the Styled TextAreas focus. Possibly if I look at the sequence of events something could be worked out but it seems un-pragmatic and odd to the user to lose the panel. Until then turning Styled off is the only solution I know for a working pipette.

Richard_Summers · November 23, 2014, 11:05pm

Will,
luckily, none of my textfields are styled, so basically your version should work totally as expected.

One question though - how do I close the color picker panel / window from any of my other windows, as I do not know the name of the color panel window?

Thanks.

Sam_Rowlands · November 24, 2014, 1:46am

To stop the color picker from altering a TextField use the following function.

Sub setUsesFontPanel(extends inTextArea as TextArea, inValue as boolean) #if TargetCocoa then declare sub mysetUsesFontPanel lib "Cocoa" selector "setUsesFontPanel:" ( obj as integer, flag as boolean ) declare function documentView lib "Cocoa" selector "documentView" ( obj as integer ) as integer mysetUsesFontPanel( documentView( inTextArea.Handle ), inValue ) #endif End Sub

Richard_Summers · November 24, 2014, 1:57am

Sam, is that a method as opposed to a function? As it doesn’t seem to return anything?
Where do I put this method / function?

I’m a bit lost now

Sam_Rowlands · November 24, 2014, 2:01am

Sorry, I copied out of a module. So if you place this code in a module, then in each TextField call this method passing in False, the OS color picker should no longer affect the TextField.

Richard_Summers · November 24, 2014, 2:05am

Thanks - will try that

So basically I call it like this:

setUsesFontPanel(False)

I ask, as I am unfamiliar with EXTENDS, and am therefore not sure if I needed to pass in 1 or 2 parameters.

Thanks.

Sam_Rowlands · November 24, 2014, 2:54am

Okay, sorry… Extends is awesome, it means you can basically add that function to what you ‘extend’. For example this method is extended to a TextField, so you can call it like below:

textField1.setUsesFontPanel( false )

or in the open event of a TextField

me.setUsesFontPanel( false )

Will_Shank · November 24, 2014, 7:05am

The color panel is a singleton, meaning there’s only ever 1 instance. In my code it’s all managed through the class PickColor consisting of only Shared items that control this single instance. To close the panel call…

PickColor.performClose

and to tell if it’s currently showing…

if PickColor.isShowing then

I should point out I’ve updated my code a little bit since that posting but it still needs polish by completing the error checking/handling and I see in Sams code he does some stuff to calibrate the color that I should add (and setUsesFontPanel!). Not sure when I’ll get a chance to do that.

Also, if you use PickColor and NSColorWell in the same project there can be crosstalk like with Styled TextAreas before Sam found the fix. Working with NSColorWell should/might be easy to account for. Really, anything that interacts with THE color panel is a source of conflict as there’s no mechanism to use NSColorPanel with exclusivity, everything is free to change it or hear of it’s changes. Unless you run it modally, but I think that’s an uncommon thing to do and wonder if Apple even sees the pipette bug as a bug.