MaterialDesignInXamlToolkit
MaterialDesignInXamlToolkit copied to clipboard
ColorPicker.Color TwoWay Binding returns wrong value if initial value was Black
Bug explanation
I have the following code:
<material:ColorPicker
Color="{Binding ViewModel.Color, Mode=TwoWay, Converter={StaticResource SystemDrawingColorToColorConverter}}"
/>
If the initial value was black, it cannot be changed. Any change from the UI to the converter will always return the initial black value.
Version
4.5.0
@HavenDV I have just tested this out in the Material Design In XAML demo app using a TwoWay binding, and I cannot spot any issues. I can see that you are using an IValueConverter in your example, are you sure you have properly implemented both the IValueConverter.Convert() and IValueConverter.ConvertBack() methods? For a TwoWay binding, the ConvertBack() method also needs a valid implementation which often is not required for (default) OneWay bindings.
https://github.com/HavenDV/Uno.Issues/tree/main/material-ui-issue
This works correctly by default, but if you change the base color to black, everything breaks.

This works correctly by default, but if you change the base color to black, everything breaks.
@HavenDV Thank you for the sample, I will look into it when I have some free time.
@HavenDV I briefly looked into the issue you're seeing. I don't actually think there is anything wrong with the values that are being set on your ViewModel. I think the confusion arises from some part of the control not being visible unless you give it an explicit size. By default, only the hue slider is visible, and that does not have an effect for certain colors (including black and white)
If you just add a ColorPicker it will look something like this. I have added a black 1px border just to show the outline of the control.

However, if you set an explicit size on the control, in this case a height of 100px, it becomes evident what the issue is.

So by simple dragging the hue slider, you're not effectively changing the color which it converts to.
The ColorPicker has a dependency property HueSliderPosition which effectively lets you move the positioning of the hue slider around the edges of the "color selection" part. Please excuse my color space lingo, I am most likely not using the correct terms.
All in all, I don't think there is a bug around the dependency property updates as such, but perhaps a default MinWidth/MinHeight of the color selection could be set such to avoid confusion? There may be use cases where the hue slider is sufficient for some user, but I really don't know. @Keboo Thoughts?
Here you can see how you can "get out" of the problem with only black being set on your ViewModel:

Thanks, I didn't know that this control has another mode. But, perhaps, for a mode without an explicit height, it is worth using the color from the slider? Because in this mode, the user will not be able to change the color if an incorrect initial color is specified for some reason.
Thanks, I didn't know that this control has another mode. But, perhaps, for a mode without an explicit height, it is worth using the color from the slider? Because in this mode, the user will not be able to change the color if an incorrect initial color is specified for some reason.
I understand your frustration, but I don't think this control was built for a scenario like that. As mentioned, the slider simply controls the hue, and if the "base color" is black, then changing the hue has no effect. You will also notice that the slider does not include black/white, so it would not be useful on its own; at least it will not let the user freely select a color (or shades of a certain color). It is not really a "mode", but perhaps the ColorPicker simply has an undesirable default size which hides a pretty important part of the control.
I think for something like this, it has to be a 2-step process to pick the desired color. An alternative you could use is to display a set of pre-calculated colors to pick from (the demo application has examples of this I believe).
Thank you for your time on this issue and for your tips. Now, understanding the problem, it is not difficult to solve it. Another idea - the second part of the control can be pop-up, appearing when changing
@HavenDV Would you be ok with closing this issue based on the above discussion? Your last comment is probably more of a feature request than a bug/issue.
Thanks for your time for this problem. Yes, I should close it. I'm currently in the process of relocating, sorry for the delay