Bug report: Text() of number gives wrong result!

[Meneghino]

Text(0.29, "#,##0.000", "en-GB") gives "0.280"

This is another one for @AndyPennell, I believe

[AndyPennell]

Yes it is, thank you Meneghino.

[v-yamao-msft]

Hi Meneghino,

Thanks for your feedback. I tried with Text(0.29,"[$-en-US]0.###","en-GB"), I got the same result with you, value “0.280” was given. I also tried with 1.29,2.29..., the same result.
While with several other values, such as 0.39, it gave a right value.

I will also try to report this issue from my side.

Best regards,
Mabel Mao

[AndyPennell · Accepted solution]

Actually the problem can be much more simpy expressed: just set a label to 0.29 and it will display as 0.280. The root casue is in the floating-point formatting code, rest assured math using the number 0.29 will work fine, but the display of this (and likely other "tricky" numbers) may be flawed, depending on the requested precision. For example Text(0.29, "#.##") works fine.

The good news is that the fix will likely result in a performance gain in the often-used code-path for displaying numbers.

Thank you for the report.

[Meneghino]

Thank you @AndyPennell, look forward to the fix.  In any case performance of PowerApps has visibly improved over the last year.

Not a major priority, but it would be good to have a way of avoiding having to parse the text of a text box in order to use its value in further manipulations and/or calculations.  This gives all sorts of issues in multi locale apps.  For example you could deprecate the Text property and have instead two properties: Value (to store the actual value and its type: text, float, integer, boolean etc.) and Format to decide how to display it.  This works very well in Excel and avoids the need to convert back and forth all the time.

Just a thought from an amateur.

[AndyPennell]

Types are coerced automatically whenever possible, for example the Text property can be set to 0.29 (a number) which is coerced into a string by PA. Another example is setting the Value property of a slider to "0.29" (a string) which is coerced into a number.

With number-to-string conversions a default format is chosen, and the Text function can then be used to override the formatting of the number.

Additionally if operators are desired (eg add 100 to a string value which is a number) then the Value funciton is explicitly needed, to turn the string into a number (eg Value("12.34") + 100), and similarly the Text value is explicitly needed when building strings (eg Text(12.34) & " approx.").

The Excel language is our model wherever possible, but our language is more strongly typed than Excel so more explicit conversions can be required.

[KarlHoffmaster]

I have not found this solution to solve the problem.  I tried your formatting suggestion above, and the text still displays incorrectly.  The value is also passed incorrectly when patched to an external data source.  This goes beyond just a "display" issue.  If you are formatting numbers directly, it works, however, if I have 3 text input fields and want to average the values of all 3, this will not work and provide incorrect results in the display, and in the data patched to a table.  

[AndyPennell]

The fix for this has not made it to production yet (it will be in the 630 release). If you can show me an example of something more than a display issue I will be happy to investigate.

[KarlHoffmaster]

Here is an example of my issue:

I have the following Fields - 

TextInput_1 (text input),  TextInput_2 (text input),  TextBox1 (text Box)

TextInput_1 Value =  1.29;  TextInput_1 Value = 1.29,  

TextBox1 Formula =  TextInput_1 + TextInput2

Reult = 2.57 instead of 2.58

I have attempted putting values around the inputs and the result and neither has worked.

Examples:

Value(TextInput_1.Text)  + Value(TextInput_1.Text);

Value(TextBox1, "#.####")

[AndyPennell]

Thank you for the example Karl.

I tried this on v610 and duplicated the problem as described ("2.570"), and then I tried it on the next release version and it displayed "2.58" as expected. It is a display problem, but my suggestion of futzing around with the format strings was not a general solution.

For example if you multiply the result of the addition by 10, it will show as "25.8" in v610.