Colorpicker ignoring user cancel


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.

Happened on Mac OSX Catalina 10.15.3 and 2019/3.1

never mind the prior comment

oddly when “show alpha” is absent things seem to work right

by changing

Selected = Color.SelectedFromDialog(UserColor, "Select a Color", True)


Selected = Color.SelectedFromDialog(UserColor, "Select a Color")

it behaves
put the trailing “true” on and it goes back to always returning true

sounds like another API 2 bug needing to be reported

Hi Norman

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
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.

You may want to have a look at graffitisuite color picker. It seems to have a cancel.

[quote=483489:@Michel Bujardet]You may want to have a look at graffitisuite color picker. It seems to have a cancel. [/quote]

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.

If you are (or become) a GraffitiSuite Desktop subscriber, I’d be happy to pass along the version with these changes if you open a support ticket.