We have a selector with {value, label} pairs such that one of the values can be 0. Setting a selected value programmatically works fine except when the value is 0 — in that case, the selector behaves as if nothing is selected. It would be a major tedious pain to re-organize our {value, label} options such that the first value is “1”, and its label “0”, second value “2”, with label “1”, etc — and it adds some amount of confusion to the code, too.
Why can’t 0 be an acceptable value when using data binding to set the value of a selector?
@Alex_Klein, we were able to reproduce the issue, an internal ticket was created - BKNDLSS-31280. We will let you know in this thread when the issue is fixed.
Unfortunately the ticket is still open. Am I correct in assuming that it is important to you? We will discuss with the team opportunity of fixing it in the nearest releases.
Kind of important before we launch to the public… but that’s still ~2 months away… I’m guessing perhaps when the data is loaded into Page Data the number 0 is interpreted as null, which perhaps affects other applications/uses for Page Data (but I really don’t know). Thnx for checking in
I’ve discovered the problem: selector values are always strings. When we assign a value to the selector as a number, it seems that this number is automatically converted into a string for the selector somewhere/somehow in the guts of Backendless… except for the number 0! So assigning a value of 1 (number) sets the value of a selector to “1” (string). But assigning a value of 0 (number) does not set the value of the selector, the selector then doesn’t have a value. Hope this helps your team
In the mean time, we are modifying our code to always make sure a string is sent to value assignments for selectors…
Thank you for your research. The issue has been fixed and the ticket has been assigned to the QA team. As soon as it is ready in production, we will let you know.
We updated cloud servers with a fix for the issue you described above. Could you check it out on your side and let us know if the fix works well for you?
we built a work-around solution by converting numbers to string, will keep that just to save time. Well done fixing the issue though 