# CStr( double ) => not working

```Dim d As Double = ( 19605 + 40 ) / 10000 thing.Text = CStr( d )```

This simple calc should output 1.9645, but in stead it gets rounded up (or down) to 1.965.

How do i show the complete double?

Just a complete guess, but try the format method to convert instead of CStr: http://documentation.xojo.com/index.php/Format

Thanks.

Now all I have to do is put Replace( outcome, “,”, “.” ) around it, because somehow in Holland the decimal points are automatically replaced by a comma and vice versa.

So where the whole worlds writes 1.9605, we write 1,9605. And yes, in large numbers we separate the 1.000.000 with a point, rather than a comma. But we do not all walk on wooden shoes, smoke weed and eat tulips all day…

Hahaha, yes, but not just Holland. South America, Europe and some parts of Africa too I think use commas. But anywhere that speaks English and China use a point.

Most people know that a point is better.

The comma vs point issue has bitten be a few times over the years in South Africa (who also uses the comma).

Victor, if you are looking for an alternative Double to Str function, you are welcome to try the one below:

``````Private Function X3_Str(d As Double) As String
if (d \\ 1) = d then // whole number?
return Str(d, "-0")
else
return Str(d, "-0.#######")
end if
End Function``````

When you use Format the “decimal vs point” becomes an issue, so I’d rather recommend you use Str instead if you want to ignore international settings.

I’m not seeing that at all. I get 1.9645. There’s something else going on here. What aren’t you telling us?

cstr is not str
if you need a not truncated result you need to use str (and if you want set how many digit you can use the format option)

str (or cstr) is not format
Format will trasform your double in a string using the local definition (on user computer) for commas and thousand separator. If you only need a string representation of your double value (ie always with the point as decimal separator) you need to use str.

CStr is more than adequate for this example. Perhaps the real scenario is different?

CSTR=>1,964
STR=>1.9645

STR<>CSTR (see documentation, first of all CSTR truncate the result)

Sheesh, so much misinformation and misunderstanding, and part of it is due to the very very bad documentation.

For instance:
The LR for the CStr() says: See the Str function for more information. But the Str docs do not give any more information related to CStr. Nothing explains what the difference is between the two. And it’s been like this for years. Gah!!

The other thing is that the difference between Str vs Format and Val vs. CDbl is still misunderstood by most. Again, thanks to bad docs and lots of forum members still suggesting the wrong one due to their own misunderstandings.

Here’s an overview, please keep this in mind and help educate everyone else:

Str + Val is a pair
Format + CDbl is different pair

• Str/Val work with a standardized textual representation of numbers, using always the US/english notation (e.g. “1.23”)
• OTOH, Format/CDbl use the localized representation that respects the user’s system-wide preferences for displaying numbers, e.g. most european countries use a comma as the floating point separator (“1,23”).

So, the simple rule is:

• If you display numbers to the user or accept user’s input of number in a TextField, use Format + CDbl.
• But if you store numberts in a file or send them over the network, expecting they’re read them again by a program, use Str + Val to make sure that a user’s change in his display preferences doesn’t break the readability suddenly.

Oh, and everyone should also know:

For a few years now, Str() can take the same formatting parameter that Format() does, e.g.:

• Str(1.23,"#.000") -> 1.230
• Format(1.23,"#.000") -> 1,230 or 1.230, depending on the user’s locale.

And anyone attempting to replace the “,” with a “.” should get a light smack on their head. Not only is this unncessary, but there may be other locales (countries) that prefer to use an even different code, so do not even start thinking doing such nonsense but learn that the OS provides functions for both localized- and standardized conversions. Not only for floating point numbers but also for Dates, for instance. If in doubt, ask! But don’t take shortcuts that will upset users outside the U.S.

Cheers for the info Thomas.

One more on the Dates, just to keep this all together:

• Date.SQLDateTime is used for inter-program exchange (analogous to Str+Val)
• Date.ShortDate and the others are used for user input/putput (analogous to Format+CStr)

[quote=35771:@Antonio Rinaldi]CSTR=>1,964
STR=>1.9645

STR<>CSTR (see documentation, first of all CSTR truncate the result)[/quote]
And yet, I get the same result, 1.9645, for both. Windows 7, 64 bit. What is your system spec?

The code:

``````  Dim d As Double = ( 19605 + 40 ) / 10000
dim s as string = cstr(d)
break``````

d is 1.9644999999
s is 1.9645

osx and italian locale

Thanks Antonio Rinaldi.

Thank also for all the other input. Str() gives the right result and ignores the point-comma issue, whereas CStr() truncates the result and ads the local point-comma settings.

Also, don’t be burned by val() for Int64’s which doesn’t work (at least in RB, haven’t tried in xojo). Use Clong() instead.

p.

please change the title of this post… there is no need for this language in a public forum