We are using kendo’s support for conditional formatting to build custom masks. For example:
kendo.toString(value, ‘\\$0;-\\$0’) // e. g. -$100 or $100
The problem is that kendo picks which side of the conditional formatting to use BEFORE rounding is applied. Thus we can end up with a display of negative zero:
kendo.toString(-.01, ‘\\$0;-\\$0’) // -$0
Note that this is similar to this issue: http://www.telerik.com/forums/issue-rounding-to-zero---getting-negative-zero, however that issue is for the built-in n2 format whereas our issue is for conditional formats.
Note that in C#/.NET, the behavior of conditional formats matches what we want:
Console.WriteLine((-.01).ToString("$0;-$0")); // $0
For reference, the reason we are building masks like this is because we have user-defined “front” and “back” symbols which should go between the negative/positive sign (or parens if we are using parens for negation) and the number itself. We thus want -$100 or ($100) instead of $-100 or $(100).
It would be great if kendo’s behavior matched .NET in this regard since it seems to be so similar otherwise and in general the .NET behavior seems preferable in most cases.
Also posted on StackOverflow:
http://stackoverflow.com/questions/39977914/kendo-format-string-puts-literal-in-the-wrong-place
http://stackoverflow.com/questions/39977630/kendo-conditional-formatting-results-in-negative-zero
11 Answers, 1 is accepted
After consulting with our developers' team, I can confirm that the described behaviour is expected.
In this scenario, I can suggest using the "c0" format to achieve similar result:
http://docs.telerik.com/kendo-ui/framework/globalization/numberformatting#types-of-number-formats
Still, as the described result is expected in many scenarios, I can suggest submitting a feature request in our UserVoice portal and based on its popularity we may implement it in a future release:
http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback
Let me know if you need additional information on this matter.
Regards,
Stefan
Telerik by Progress
Rank 1
Hi Stefan,
We can't actually use the "c0" format for our use-case. In the example, the '$' is just a placeholder. For us this is a user-defined value and could be an arbitrary currency symbol, units, etc.
We also rely on conditional formatting to allow for customization of how negative numbers display (e. g. "($10)" vs. "-$10").
As you say, the current behavior is not what devs or users generally want/expect, so I do consider this a bug rather than an enhancement request.
Nevertheless, I'm happy to file a request for this on UserVoice as well.
Rank 1
Thank you for the feedback and the feature request.
Your notes for the current behaviour of the widget were forwarded to our developers' team.
Let me know if you need additional assistance on this matter.
Regards,
Stefan
Telerik by Progress
Rank 1
I can agree with that.
The may point is that once this is already implemented, many users are considering it expected, and changing now will cause a breaking change.
This is why will considered the feature request as if a major part of the community thinks that we have to change it, we will.
We are trying the constantly improve based on the feedback.
Regards,
Stefan
Progress Telerik
Rank 1
[quote]The may point is that once this is already implemented, many users are considering it expected, and changing now will cause a breaking change.[/quote]
I understand that breaking changes are a concern, but at the same time my guess is that no one actually wants the behavior in place today.
One option could be to take a compatibility flag approach, e. g.
kendo.compatFlags.toStringOutputsNegativeZero = false;
This gives people an escape hatch to reenable the old behavior if they rely on it.
Thank you for the suggestion.
I will forward this again to the developers to see if we can consider this in some of the future releases.
Expect someone from the developers' team to provide more details this week.
Regards,
Stefan
Progress Telerik
We discussed the behavior with the developers team and this is a core feature used in the components. It was initially implemented to work like this and changing it would cause a major breaking change. Adding a property would also require changing internal logic that can result in a breaking change.
I apologize for any inconvenience this behavior may cause you. A workaround to some extent can be calling Math.round for the value before passing it to kendo.toString.
Regards,
Viktor Tachev
Progress Telerik
Rank 1
Hi Viktor,
Thank you for following up with the dev team. Some thoughts:
[quote]this is a core feature used in the components[/quote]
Which components rely on the return value "-0"?
[quote]It was initially implemented to work like this[/quote]
Can you clarify this? Does Telerik believe that the current "-0" behavior is correct/desired by most customers or is it the case that this is just what the code happens to do today?
[quote]Adding a property would also require changing internal logic that can result in a breaking change.[/quote]
I don't follow. Making any change at all COULD result in a breaking change; that's why we have tests. The idea of a compat flag is to fix the bug while still allowing oddball consumers who relied on the legacy behavior to have an escape hatch.
I understand your position and am not saying that such behavior is right or wrong. However, it was implemented like that and changing it will be a breaking change.
I have forwarded your suggestions it to the developers and they will consider the options for adding a flag in a future release of the components. With that said, I am afraid that currently such modification is not included in the planning.
Regards,
Viktor Tachev
Progress Telerik