Taking a cue from what we said in the previous discussion on numbers "If someone can explain it to me?" I did a test.
I don't think it is possible in an application to replace the numerical initialization from System.Double to System.Decimal because the behavior is not identical, see image and a Xide test application.
Danilo
Still number
- softdevo@tiscali.it
- Posts: 191
- Joined: Wed Sep 30, 2015 1:30 pm
Still number
- Attachments
-
[The extension viaef has been deactivated and can no longer be displayed.]
-
- img.JPG (15.86 KiB) Viewed 914 times
Still number
Hi Danilo,
Yeah, when you print a Decimal, you need to specify how many decimal places to include, because it does not contain the extra formatting information that FLOAT has:
LOCAL d AS Decimal
d := 123.1234567
? d:ToString("N2")
d := 12
? d:ToString("N2")
Yeah, when you print a Decimal, you need to specify how many decimal places to include, because it does not contain the extra formatting information that FLOAT has:
LOCAL d AS Decimal
d := 123.1234567
? d:ToString("N2")
d := 12
? d:ToString("N2")
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
- Posts: 774
- Joined: Wed May 17, 2017 8:50 am
- Location: Germany
Still number
Hi Chris,
i think there must have been a problem in the origin 2.0.0.9 build. When i switch back to that version i can confirm what Danilo is seeing. But with the newer dlls i have, the decimal and double output is as expected "8,70" and "870,00". When i change the decimal setting with the origin build to e.g. setdecimal (3), the decimals output is still "9" and "870" , while the doubles are "8,700" and "870,000". With the newer Dlls the output is in both cases "8,700" and "870,000".
regards
Karl-Heinz
i think there must have been a problem in the origin 2.0.0.9 build. When i switch back to that version i can confirm what Danilo is seeing. But with the newer dlls i have, the decimal and double output is as expected "8,70" and "870,00". When i change the decimal setting with the origin build to e.g. setdecimal (3), the decimals output is still "9" and "870" , while the doubles are "8,700" and "870,000". With the newer Dlls the output is in both cases "8,700" and "870,000".
regards
Karl-Heinz
Still number
Ah, right, thanks Karl-Heinz, Robert made some changes in this area indeed. Can't send new runtime dlls now, as they are in an intermediate state, but we will soon have a new build ready, Danilo please test again when it gets released.
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Still number
Ciao Danilo,
if you replace the NTrim() function call with the ToString() method call, as follows:
it works as expected:
Wolfgang
if you replace the NTrim() function call with the ToString() method call, as follows:
Code: Select all
local cVal as string
local nVal,nVal1 as System.Decimal
cVal := "8.70"
nVal := Val(cVal)
self:oLabel2:Text := nVal:ToString() // NTrim(nVal)
nVal1 := (nVal*100)
self:oLabel1:Text := nVal1:ToString() // NTrim(nVal1)
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
- softdevo@tiscali.it
- Posts: 191
- Joined: Wed Sep 30, 2015 1:30 pm
Still number
Yes thank you, but I would have to change thousands of lines of code with the risk of making mistakes that come out only at runtime.
Danilo
Danilo
Still number
Hi Danilo,
of course, if you have it used that much!
But when you change all these places to the system.decimal datatype, you have to check it nevertheless, because things that worked previously could give unexpected results (more precise).
Wolfgang
P.S. I'm waiting for the DBFCDX RDD so I can finally move my accounting program (il mio programma di contabilità) and get rid of all the problems that are facing up from time to time.
of course, if you have it used that much!
But when you change all these places to the system.decimal datatype, you have to check it nevertheless, because things that worked previously could give unexpected results (more precise).
Wolfgang
P.S. I'm waiting for the DBFCDX RDD so I can finally move my accounting program (il mio programma di contabilità) and get rid of all the problems that are facing up from time to time.
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it