Page 1 of 1
Transform() of simple numeric values
Posted: Thu Jul 20, 2023 10:03 am
by stefan.ungemach
Probably I got something wrong, but can anyone please explain this:
- transform.png (5.37 KiB) Viewed 983 times
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
Posted: Thu Jul 20, 2023 10:35 am
by Chris
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?
Transform() of simple numeric values
Posted: Thu Jul 20, 2023 11:30 am
by stefan.ungemach
Playing around with the settings didn't change anything, but maybe it helps to know that
transform( fValue, "999,999" )
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() of simple numeric values
Posted: Thu Jul 20, 2023 12:16 pm
by Chris
Hi Stefan,
Understood, but can you please generate a small standalone sample showing this behavior so we can reproduce it here and fix it?
Transform() of simple numeric values
Posted: Fri Jul 21, 2023 9:31 am
by stefan.ungemach
Please consider it (almost) solved, I found the problem: Hidden deeply in our code there was a new
SetThousandSep(Asc(""))
which caused the problem.
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
Posted: Fri Jul 21, 2023 11:42 am
by Chris
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..
Transform() of simple numeric values
Posted: Mon Jul 24, 2023 7:23 am
by robert
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
Transform() of simple numeric values
Posted: Mon Jul 24, 2023 7:30 am
by stefan.ungemach
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.