66568 - double.tostring raises and invalidargument exception when a multipart format is used

Feedback Case Number: 66568

I think Greg did not understand the problem.


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

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.

I hope this is clear.

From: UTR #35: Locale Data Markup Language

A pattern contains a postive and negative subpattern, for example, “#,##0.00;(#,##0.00)”.

If they are following Unicode TR35, there’s no 3rd argument.
Just the positive and negative formats, not a “Zero format”.

Docs should remove the use of a “3rd format” (zero), and Exceptions should exist accordingly in all platforms for consistency.


I think the table you posted is from https://documentation.xojo.com/api/text/format.html and that accepts a 3rd parameter.

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.

I hope now the case is clearer.

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)"))

I guess that happens in Windows.

Just tested it on Mac and it works as documented:

  • positive number gives 123.45
  • negative number gives (123.45)
  • 0 gives zero!

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.

I don’t think Xojo will change how Format works.

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?

You can “request the reopening of the case” there. Explain your reasons there.

Click in the Status:

But what you want to point out slightly differs from such case. Better create a new specific one.

Thank you, I know, I already did yesterday.

Just don’t want the case to die there, if no one will review it and a new case will be better to explain exactly the problem in mac.