Probably I got something wrong, but can anyone please explain this:
Lots of code from VO which format numeric values suddenly produce inexplicable results because they deliver not only nonsense from a certein value of the numeric parameter but also write some utf16 code into the result.
Transform() of simple numeric values
-
- Posts: 71
- Joined: Thu Jul 15, 2021 10:46 am
- Location: Germany
Transform() of simple numeric values
Hi Stefan,
I could not reproduce this, but I'm sure it has to do with the settings used in the app. Can you please try reproducing this in a small standalone sample and send it to have a look?
I could not reproduce this, but I'm sure it has to do with the settings used in the app. Can you please try reproducing this in a small standalone sample and send it to have a look?
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
- Posts: 71
- Joined: Thu Jul 15, 2021 10:46 am
- Location: Germany
Transform() of simple numeric values
Playing around with the settings didn't change anything, but maybe it helps to know that
produces a chr(0) instead of the commas. If fValue<=999 there is no comma and the result is ok. If it is 1000 there would be a comma and the result is truncated there in the debugger because of the chr(0).transform( fValue, "999,999" )
Transform() of simple numeric values
Hi Stefan,
Understood, but can you please generate a small standalone sample showing this behavior so we can reproduce it here and fix it?
Understood, but can you please generate a small standalone sample showing this behavior so we can reproduce it here and fix it?
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
-
- Posts: 71
- Joined: Thu Jul 15, 2021 10:46 am
- Location: Germany
Transform() of simple numeric values
Please consider it (almost) solved, I found the problem: Hidden deeply in our code there was a new
But this raises another little question: Speaking with the developer I understand that he wanted to make temporarily sure there are no thousand separators in the result of any transformations. What he intended to get was just nothing between the digits instead of a chr(0). The XSharp behaviour here is exactly the same as in VO, so we don't have a bug - but is there a global setting allowing the given goal of
transform(1000,"999,999,999")
giving just " 1000" ?
which caused the problem.SetThousandSep(Asc(""))
But this raises another little question: Speaking with the developer I understand that he wanted to make temporarily sure there are no thousand separators in the result of any transformations. What he intended to get was just nothing between the digits instead of a chr(0). The XSharp behaviour here is exactly the same as in VO, so we don't have a bug - but is there a global setting allowing the given goal of
transform(1000,"999,999,999")
giving just " 1000" ?
Transform() of simple numeric values
Hi Stefan,
Only way I can think of, is to redefine Transform() in your code, so that it adjusts the result, based on a global setting, something like:
GLOBAL glRemoveSeparatorsFromTransform AS LOGIC
FUNCTION Transform(fValue AS FLOAT, cPic AS STRING) AS STRING
LOCAL cOriginal AS STRING
cOriginal := XSharp.RT.Functions.Transform(fValue, cPic) // get the result from the original Transform() from the X# runtime
IF glRemoveSeparatorsFromTransform
RETURN cOriginal:Replace("." , "") // or ",", depending what you use for thousands separator
END IF
RETURN cOriginal
FUNCTION Transform(uValue AS USUAL, cPic AS STRING) AS STRING
LOCAL cOriginal AS STRING
cOriginal := XSharp.RT.Functions.Transform(uValue, cPic)
IF glRemoveSeparatorsFromTransform .and. IsNumeric(uValue)
RETURN cOriginal:Replace("." , "")
END IF
RETURN cOriginal
If you put this in a base lib, then all of your own calls to Transform() will resolve to this one and should have the result you need. Problem is that when Transform() is called from within the SDK code (not from your code that you compile), then the original Transform() will still be called, not sure if this is a problem for what you need this for..
Only way I can think of, is to redefine Transform() in your code, so that it adjusts the result, based on a global setting, something like:
GLOBAL glRemoveSeparatorsFromTransform AS LOGIC
FUNCTION Transform(fValue AS FLOAT, cPic AS STRING) AS STRING
LOCAL cOriginal AS STRING
cOriginal := XSharp.RT.Functions.Transform(fValue, cPic) // get the result from the original Transform() from the X# runtime
IF glRemoveSeparatorsFromTransform
RETURN cOriginal:Replace("." , "") // or ",", depending what you use for thousands separator
END IF
RETURN cOriginal
FUNCTION Transform(uValue AS USUAL, cPic AS STRING) AS STRING
LOCAL cOriginal AS STRING
cOriginal := XSharp.RT.Functions.Transform(uValue, cPic)
IF glRemoveSeparatorsFromTransform .and. IsNumeric(uValue)
RETURN cOriginal:Replace("." , "")
END IF
RETURN cOriginal
If you put this in a base lib, then all of your own calls to Transform() will resolve to this one and should have the result you need. Problem is that when Transform() is called from within the SDK code (not from your code that you compile), then the original Transform() will still be called, not sure if this is a problem for what you need this for..
Chris Pyrgas
XSharp Development Team
chris(at)xsharp.eu
XSharp Development Team
chris(at)xsharp.eu
Transform() of simple numeric values
Stefan
Chris his solution is probbably the best for you.
But I do not understand why you would want to globally override this behavior.
That does not make sense to me at all.
When I specify in my code
then it is clear that I want a thousand separator.
No global setting should try to prevent that.
Robert
Chris his solution is probbably the best for you.
But I do not understand why you would want to globally override this behavior.
That does not make sense to me at all.
When I specify in my code
Code: Select all
transform( fValue, "999,999" )
No global setting should try to prevent that.
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
The Netherlands
robert@xsharp.eu
-
- Posts: 71
- Joined: Thu Jul 15, 2021 10:46 am
- Location: Germany
Transform() of simple numeric values
Robert,
it does make sense if you have a generic serializer (our is vaguely based on the XMLParser class of Anthony Smith) whose results may be passed to a SQL statement. According to the comments there seem to be restrictions in some dialects regarding separators in the string representation of numeric values. However I understand that this should be handled on a str() base and I don't really understand why that matters at all. But our problem can be solved by simply saving the result of getThousandSep() and restore it after serialisation anyway, which hadn't been done so far.
it does make sense if you have a generic serializer (our is vaguely based on the XMLParser class of Anthony Smith) whose results may be passed to a SQL statement. According to the comments there seem to be restrictions in some dialects regarding separators in the string representation of numeric values. However I understand that this should be handled on a str() base and I don't really understand why that matters at all. But our problem can be solved by simply saving the result of getThousandSep() and restore it after serialisation anyway, which hadn't been done so far.