Color dialog cancel

djigneo

Is there a way to determine if the user cancelled the Color dialog?

var dzColor = ColorDialog.getColor();// dzColor is (0, 0, 0) if cancelled

Black could be a legitimate selection, right? So is there a way to determine if the user cancelled? The way I've seen it on other dialogs is to use connect to have the 'Accept' or 'Cancel' button call a function. I'm not seeing anything obvious from the debugger or from the API for ColorDialog. (I have checked to see if dzColor was undefined, but it seems to return an instantiated Color regardless of 'Accept' or 'Cancel'.)

Any clues?

Richard Haseltine

There is an option to pass a colour when running the dialogue - if you do that, does cancel return the passed colour? If so would treating that as a do nothing work?

rbtwhiz

ColorDialog is a global QObject that wraps the public static members on QColorDialog.  As such, you don't have access to other QColorDialog functions - inherited or otherwise.  Your routine would need to capture the current value of whatever Color you're exposing, compare it to the result of the ColorDialog.getColor() call and respond according to that comparison.

-Rob

djigneo

Richard,

No, as I mentioned in the OP, if the user cancels the ColorDialog window, the result is an instantiated Color object set to black (0, 0, 0). (I did indeed experiment with this parameter, but kept it out of the OP, because an initial color isn't relevant when black is a legitimate selection.) Comparing to the initial color is also a no-go because the user could legitimately accept that color as well.

var dzColor = ColorDialog.getColor(new Color(255, 0, 0));print(String("%1, %2, %3").arg(dzColor.red).arg(dzColor.green).arg(dzColor.blue));// cancel// result = 0, 0, 0

 

Rob,

In the above example, how would I know the difference between the user cancelling and the user selecting black intentionally?

rbtwhiz

djigneo said:

var dzColor = ColorDialog.getColor(new Color(255, 0, 0));print(String("%1, %2, %3").arg(dzColor.red).arg(dzColor.green).arg(dzColor.blue));// cancel// result = 0, 0, 0

...

In the above example, how would I know the difference between the user cancelling and the user selecting black intentionally?

You wouldn't without additional supporting code, which is why I made the comment...

rbtwhiz said:

Your routine would need to capture the current value of whatever Color you're exposing, compare it to the result of the ColorDialog.getColor() call and respond according to that comparison.

You're offering the user the ability to select a color... Whatever the reason is, you presumably initialize your routine using a 'current' color of some sort.  If the color isn't changing from the 'current' then the need to perform an operation based on a change to that color is diminished.  Is handling that as simple as being able to instantiate QColorDialog and using that instance like a DzBasicDialog or DzDialog instance?  No... but its what you currently have access to.  Do I recognize, and does it bother me, that this is inconsistent?  Yes... to both.

-Rob

Richard Haseltine

Could you create a custom dialogue using DzColorWgt? Then, presumably, you could have Acept and Cancel buttons, and retrieve the colour only if Accept was clicked.

djigneo

My actual use case is that I'm using the ColorDialog as the only dialog in a script, since the only input is a color (and selected Scene nodes). When the ColorDialog is cancelled, my script executes, setting the color value to black. It's been fine for my purposes, but I was looking for a way to let 'Cancel' abort the script.

The ideal API consumption from my perspective would be for ColorDialog.getColor() return undefined if the user cancels. I fail to see a case where getting an instantiated Color object returned is useful if the dialog was cancelled. I don't mean to nitpick, just sharing my perspective (is there a compelling reason I'm missing?). (I'm sure modifying this isn't exactly on the agenda also.) 

Off-topic: Are there any articles on QObjects? I presume based on context that they're the back-end classes (C++ perhaps), and DAZ Script only "wraps" certain methods. Your explanation is useful, but I don't fully understand the domain-specific "lingedy".

Edit: Response to Richard

Yes! Proof of concept:

var oDialog = new DzBasicDialog();var oColorWgt = new DzColorWgt(oDialog);var bAccepted = oDialog.exec();

bAccepted is true if the user pressed 'Accept', else false. This works because the DzColorWgt object is smart enough to know if the ColorDialog was cancelled or not.

rbtwhiz

djigneo said:

The ideal API consumption from my perspective would be for ColorDialog.getColor() return undefined if the user cancels. I fail to see a case where getting an instantiated Color object returned is useful if the dialog was cancelled. I don't mean to nitpick, just sharing my perspective (is there a compelling reason I'm missing?). (I'm sure modifying this isn't exactly on the agenda also.)

rbtwhiz said:

ColorDialog is a global QObject that wraps the public static members on QColorDialog.

The methods on ColorDialog are literally wrappers for the public static members on QColorDialog.  The getters on this class literally consist of a single statement that returns the return value from the QColorDialog equivelent call.  As QColorDialog::getColor() returns an invalid color if the dialog is rejected, I've just added Color::isValid() to the 4.9 dev branch so the validity of a Color can be checked like so...

var clrTest = ColorDialog.getColor( new Color( 0, 0, 0 ) );print( clrTest.red, clrTest.green, clrTest.blue, clrTest.isValid() );

Richard Haseltine said:

Could you create a custom dialogue using DzColorWgt? Then, presumably, you could have Acept and Cancel buttons, and retrieve the colour only if Accept was clicked.

Yes, you can certainly create a Simple Dialog with a DzColorWgt and use the return value from DzDialog::exec() to control whether the value of the color widget is used... but I didn't offer that as answer because it isn't what was asked for.  I assumed, and @djigneo later confirmed, that this dialog was intended as the only prompt to the user; i.e. cause the user the least number of clicks to perform the operation.  Creating a dialog with an intermediate widget adds clicks.  The original question was if there was a way to determine whether a DzColorDialog was cancelled... which there isn't in 4.8, but I've added to 4.9, as described above.

-Rob

djigneo

Thank you, @rbtwhiz you are the man! Great information as always, and thanks for the code update!

MantaMade

May I also just say thank you to @rbtwhiz, a new post to a very old thread, this had me going for a while but you helped a ton.

Man7a