Var d As Double = -123.45
Var s As String = d.ToString("#.00;(#.00);0.00")
Windows 10: Invalid Argument exception (this is correct)
Mac: No Exception but the argument is not correct (this is wrong)
The Unicode Number Format Patterns page mentions subpattern for negative numbers, so the correct and valid patter is not
#.00;(#.00);0.00
but
#.00;(#.00)
What is expected is that Windows and Mac (Linux too) complain with Invalid Argument Exception when a wrong pattern is used. This is not happening on Mac and a result with the “normal” patter is used: -123.45 instead of (123.45)
If I remove ;0.00 from the pattern, then the result on mac is correct with (123.45)
I can even change the patter to “#.00;#.00-” to get 123.45- instead, so that patter is working as expected.
There is no third pattern of 0 value (that is different than Str), so if we add a third pattern on Mac it should report an Invalid Argument Exception just as Xojo does with Windows.
Double.ToString follows the Unicode standard (no 3rd parameter), and from what I understand on the case, Windows (correctly) throws an error and Mac doesn’t. Mac should throw an error too because a 3rd parameter is not valid for Double.ToString. If I remove the 3rd parameter on Mac then the correct negative format is shown (123.45) and not -123.45 when using the invalid format.
Exact same “function”, different parameters and outcomes = inconsistency.
Choose a pattern/standard, stick with it.
Some places TR35, some places proprietary interpretation, causes more damage than benefit.
I would prefer announcing a “breaking change” for, let’s say 2022 r1, and assume the TR35 in all places, and raising an exception in case of finding the “zero format” (3rd format parameter) in all platforms. Such 3rd parameter must be rare, few people will be affected, and those will need to update it. If they don’t, exceptions will occur and they will find the documented situation and suggested fix, like:
This legacy code raises an “Invalid Argument exception”:
Var s As String = Format(v, "0.00;(0.00);\z\e\r\o\!")
That can be solved by, for example:
Var s As String = If(v=0, "zero!", Format(v, "0.00;(0.00)"))
Edit: Or are you saying that Xojo should change what Format does right now? In other words, Format works now and you want Xojo to change the behavior to raise an exception
I’m saying, again, I would prefer one standard everywhere. And the only popular standard I know that Xojo supports for number/dates/etc formats is the UTS TR35. And malformed format strings should raise exceptions.
Back to the original case. @Greg_O_Lone closed the case because he read the first post saying that in Windows using a wrong pattern an Error is shown. This is “by design”, the problem is that the second post on the same case mentions that on mac this doesn’t happen. There is a bug here, not what the original post says, but what the Mac is not doing.
My question to Xojo staff: how likely is it for you to reopen the case and fix the bug on mac or is better to create a new case with this information?
