I’m using the built-in colorpicker of Xojo which in general is working fine. The only thing that is not working: If I close the opened colorpicker dialog without choosing a color the current set color still be used (Boolean = True). Here is my code:
[code]Var UserColor As Color
Var Selected As Boolean
// choose the default color shown in color picker
UserColor = Color.CMY(0.35, 0.9, 0.6, 0)
Selected = Color.SelectedFromDialog(UserColor, “Select a Color”, True)
If Selected = True Then
ConsolePreview.BackgroundColor = UserColor
End If[/code]
I don’t know how to omit the color parameter of SelectedFromDialog but then I assume (based on the documentation) that it’s still returns true and black is returned/set.
Thanks for the answer! I already tried to omit the last True (Alpha, Mac only) but Selected then is still True. Just tried again but still always true. For testing I close the Colorpicker by the red close button (no other option).
Okay, I made some further testings…
I changed my code to test the return value of Selected:
If Selected = True Then
MessageBox(“True”)
Else
MessageBox(“False”)
End If
First Open colorpicker and closed by red window button returns TRUE Second Open colorpicker and closed by red window button returns FALSE Any further opening returns FALSE
As soon as I change the color in the colorpicker and then press the red close button it’s TRUE again (for the next two times opening it and not changing color).
Btw. I’m opening the Colorpicker in a movable modal window and the Colorpicker is always behind the movable window.
Aaaah, I see the problem: There is no kinda “OK” button in the Colorpicker of Mac. So the only choice is to use the red close button. I don’t know how to solve this problem from Xojo perspective.
Indeed, the built in color picker has no cancel button, and since it is a system thing, you can’t monitor user action. Perhaps Apple engineers assume that if no color has been picked but the default, it is equivalent to cancel.
I precisely used it yesterday and noted the same bug.
In my case it is not too much of an issue, since it is called from a window where the user can click Cancel to prevent change in color.
I ran the graffiti suite color picker demo, but clicking cancel in the color picker window doesn’t appear to cancel, it applies the selected-but-not-wanted color to the sample in the main window. Can anyone tell me if the actual graffiti suite code behaves this way, or if it’s just a bug in their demo app?
This was an oversight as I updated it to push real-time selections to the selector itself. The next release will have a property which controls that functionality and, if not real-time, show the Cancel button.