Tim, this is unnecessary. I’m a gentleman. I can ignore you under your request. Consider done. If my name is not invoked, I’ll just answer other people and ignore you as you wish.
If you provide both, positive and negative masks, it will work, and will be future proof.
always something new to learn - I didn’t know about two masks, thanks 
1 Like
IIRC to only way to be sure to get a non scientific format string is to stuff the number into a variant and get Variant.StringValue…
I have had to use that workaround more than once!
-Karen
1 Like
Format or ToString with a format that indicates you want all numbers does the trick.
The point I was trying to make was that shouldn’t be necessary in a low-code environment meant for building applications quickly. If I wanted a scientific form of the number, I would have asked for it with the format.
Prior to this change, API 2 made it really simple and it was reason for me to praise the new API. The change itself makes me question just how much Xojo is really planning anything.
With using a variant you don’t need to specify the format and you always get all the digits for the data type…
Perhaps there should be one formatting input setting to explicit specify outputting a string with full precision for any input data type … as that is what I often want… That would be more RADish than having to format for that when that is what you want… And for me that usually winds up when the number is going into a DB eventually. Raw data should not be massaged.
100% Agree…
That speaks to likely not having detailed written specifications for functions outputs …
That is far from the first time something like that has happened over the years.
-Karen
I can’t find information on ‘not using a pattern’, so my guess is that the change to showing scientific notation without a number pattern is a Xojo interpretation.
Just like having this:
DateTime.Now.SecondsFrom1970.ToString(locale.raw)
produces a number formatted with grouping character (like 1,685,300,662.784 on my machine)
2 Likes
Format can use 3 masks (extra one for zero value), ToString can use 2.
From the docs:
Format
https://documentation.xojo.com/api/text/format.html#format
The formatSpec can be made up of up to three formats separated by semicolons. The first Format is the Format to be used for positive numbers. The second Format is the Format to be used for negative numbers and the third Format is the Format to be used for zero.
ToString
http://unicode.org/reports/tr35/tr35-4.html#Number_Format_Patterns
A pattern contains a postive and negative subpattern, for example, “#,##0.00;(#,##0.00)”. Each subpattern has a prefix, a numeric part, and a suffix. If there is no explicit negative subpattern, the negative subpattern is the localized minus sign prefixed to the positive subpattern.
1 Like
That still puts in the commas so not really ‘raw’. Is there a way to get that string WITHOUT the commas?
-Karen
2 Likes
I think Alberto is trying to illustrate another of the Xojo-thinks-they-know-better-than-standards bugs.
The code Rick mentioned will get you the string without commas. You can also just use “#” as a format shortcut to force all numbers for the purpose of Unix Timestamps. Might need “#.#” to include the decimal if you desire it.
1 Like
Yes, the documentation here: Double — Xojo documentation says
If no locale is specified, then Locale.Raw is used.
and this is not the case, without locale we get a scientific notation (for SecondsFrom1970), with locale.raw we get a number with group separator.
1 Like
That’s a bug. Locale.Raw should be the neutral POSIX (AKA C) equivalent. And its definition is
LC_NUMERIC
# This is the POSIX locale definition for
# the LC_NUMERIC category.
#
decimal_point "<period>"
thousands_sep ""
grouping -1
#
END LC_NUMERIC
That means no thousands separation and a dot at the decimal place, just it.
This demands an Issue Report.
2 Likes
It has already been reported.
#72807 - Double.ToString: If no locale is specified, then Locale.Raw is used - is not the case
2 Likes