FreakyPicker ignores BackgroundColor

[janusw]

Description

The FreakyPicker control seems to ignore the property BackgroundColor completely. There is no visual change if I add it.

I have only observed this on Android so far. Have not checked iOS.

Code

To reproduce, simply add a BackgroundColor to the picker in the sample (at tag v0.5.0).

            <freakyControls:FreakyPicker
                Title="Select something :D"
                <!-- some more propeties ... -->
                TextColor="Black"
                TitleColor="LightGray"
                BackgroundColor="Purple"/>

Expected Behavior

The background should be colored in the requested color.

Actual Behavior

It does not change.

Basic Information

• Version with issue: 0.5.0
• Last known good version: ?
• IDE: VSCode on Mac
• Platform Target Frameworks:
  • Android: Android 14 / API level 34
  • iOS: ?
  • Dotnet: 8.0.402
• Target Devices:
  • Samsung Galaxy S21

[FreakyAli]

Can you also check if this bug exists on the Maui picker control

[janusw]

Yes, on the standard MAUI Picker I can change the BackgroundColor without any problem.

[FreakyAli]

@janusw I checked this, it seems that when you set the background to transparent (for the underline), it removes it altogether and does not let you change the color again, adding it back brings back the underline...

[janusw]

@janusw I checked this, it seems that when you set the background to transparent (for the underline), it removes it altogether and does not let you change the color again

You mean this here?

https://github.com/FreakyAli/Maui.FreakyControls/blob/56e033ccc79385bc439065cd2e7d66ddcc2babb8/MAUI.FreakyControls/MAUI.FreakyControls/Platforms/Android/FreakyPickerHandler.android.cs#L18-L19

adding it back brings back the underline...

So what you're saying is: You're setting the background to transparent on Android, in order to make the underline disappear? Therefore the inability to change the background color is a side-effect of your implementation on Android. Correct so far?

If yes, then I guess these are the options for dealing with it:

• Override the BackgroundColor property to make it read-only / not settable (if possible?).
• Or: At least document the fact that the BackgroundColor is not changeable for FreakPicker on Android.

[FreakyAli]

@janusw Yes, this seems to be why it's happening,

Override the BackgroundColor property to make it read-only / not settable (if possible?).

I was thinking of doing the same thing, maybe even re-implement how it works and see if that does anything for Android

Or: At least document that the BackgroundColor is not changeable for FreakPicker on Android.

It's not just the picker, more controls are using this like Entry, DatePicker, TimePicker and others....

[FreakyAli]

For the time being you can wrap it in a Layout and give it a background color if you want a Color other than transparent

[FreakyAli]

Closing this since it's a native thing that cannot be changed, pining it just in case!

[janusw]

Closing this since it's a native thing that cannot be changed, pining it just in case!

Interesting strategy to deal with a valid bug report. The recommended way would be: Fix it and then close the issue. It certainly is fixable. Or: If you decide it's not feasible to fix it, then at least document it as a shortcoming of your implementation (as suggested above).

These are just my recommendations, though. I don't actually care, since I decided that your lib is not fit for productive use (concerning my specific use case, at least).

[FreakyAli]

I already tried every possible way to fix the bug and the issue is the .NET MAUI api that sets the background color resets the Background property so as long as I can't change the internal implementation of the Background property this is unfixable, I'm sure they won't be changing that just to support my library 🙂

If you think this is so easy to fix you can give it a try but I'm sure you have better things to do, anyways I was going to document it ergo I pinned the issue, as I do this in my free time and it's an unpaid project, anyways I am sure you're correct that my library is unfit for use, thanks for your feedback really appreciate it 🙂

[FreakyAli]

Documentation is now up to date

[janusw]

Documentation is now up to date

Alright, thanks. Sorry for my snippy comment, but I do think this is the least you should do. In particular since documentation is really the only thing that distinguishes a feature from a bug 😜

[FreakyAli]

I was gonna do it anyway, the whole point of pinning was to remember that like I said earlier...