TOPIC:

#1: I noticed that the default decimal setting for XSharp is 2, but the following code using VAL returns only one decimal place:
Shouldn't that return 7.45 ?

#2: In Foxpro, if a dollar sign is prepended to an amount string then VAL() returns a currency variable
Foxpro does not support any other currency symbols beside the dollar, which seems rather US-centric. It might be good if XSharp supported other common currency symbols as well.

Kevin,
Thanks for the report. We'll make sure that the $ sign will be recognized by the Val() code and will return a Currency from that.
Accepting other currency symbols is another thing. What we can do is this: always recognize the $ character and also the symbol from the settings in the NumberFormatInfo from the current thread (docs.microsoft.com/en-us/dotnet/api/syst...tinfo.currencysymbol)
I have created a ticket for this: github.com/X-Sharp/XSharpPublic/issues/385

Robert

Hi Kevin,

In addition to what Robert said, about #1, I could not reproduce this. Can you please post a complete example showing this?

I could not reproduce error # 1 either...

See:

When I said the value of valreturn was 7.5, I determined that by using the debugger and holding the cursor over the valreturn variable, rather than actually printing it. If you print it, it does come out as 7.451. I notice, however, that while the debugger gives the 7.5 value while holding the cursor over valreturn, if you dig down into the properties of valreturn it says the value is 7.451. I don't know whether that difference in reported value is a debugger error or just the way the debugger works.

I think, though, that the 7.451 value is still the wrong return value (or at least not what Foxpro would return) since DECIMALS is set to 2.

Kevin Clark wrote: Shouldn't that return 7.45 ?

Nope. In Vfp check

#2: In Foxpro, if a dollar sign is prepended to an amount string then VAL() returns a currency variable

local valreturn
valreturn=VAL("$7.45") // returns 7.4500 and VARTYPE=currency in Foxpro; returns 0 and vartype=long in XSharp

Foxpro does not support any other currency symbols beside the dollar, which seems rather US-centric. It might be good if XSharp supported other common currency symbols as well.

Even weirder at first encounter in vfp:Actually having only a single marker to decide if a string is a currency is probably a benefit, as comparing to user machine setting might introduce further problems.

Hi Kevin,

Thanks for the clarification! I did a couple tests with VFP and this:


returns 123.456 and 123.46, so in VFP, even if decimals is set to 2, in the first case it actually prints 3 decimal points. So apparently the difference is only in how Val() works compared to X#/VO, if I understand it correctly, in VFP it uses the DECIMALS setting to decide how many digits to parse and discards the rest, is that correct? Will log this as a bug to be fixed.

Chris wrote: in VFP it uses the DECIMALS setting to decide how many digits to parse and discards the rest, is that correct? Will log this as a bug to be fixed.

Hi Chris,
not the way I see it:

Thanks, I was wrong. So I tried this:


and the result is

123.456 123.46
123.45600 123.45600

do you know what causes the difference in the first case, between printing (without Str()) the value that is assigned as a literal in contrast to the same value that was assigned from Val() ?

It seems like STR and VAL should both respect the default DECIMALS setting, but in Foxpro they don't. VAL respects the DECIMALS setting but STR does not. So that, with DECIMALS set to 2:

You can use SET DECIMALS and SET FIXED together so that floats are displayed as a set length; but STR still doesn't respect this:

...and that brings us to a similar to dozens and dozens of similar cases we had when trying to implement VO features in X#, in a way that is compatible with VO...how would you guys suggest we should handle in X# this behavior of VFP? Try to emulate it, or make it more consistent?

Kevin, there is some confusion, here. STR() is a string function, it does not, and should not, depend on decimals or fixed settings. The ? command takes the string that STR() returns and displays it verbatim, as it does with any other string value.

The ? command only looks at the numeric display settings when it has to display numeric values. Otherwise, it ignores them, as it should.

Kevin wrote

Foxpro does not support any other currency symbols beside the dollar, which seems rather US-centric. It might be good if XSharp supported other common currency symbols as well.

The $ sign is used in VFP to set Currency literals. It does not influence the currency symbol that is used to display monetary values, that can be set to different settings, as Thomas already demonstrated. But it does not affect literals, in the same way that setting the decimal point to a comma, instead of a period, does not change how the VFP parser interprets a numeric literal.

Kevin Clark wrote: It seems like STR and VAL should both respect the default DECIMALS setting, but in Foxpro they don't. VAL respects the DECIMALS setting but STR does not. So that, with DECIMALS set to 2:

? STR(7.451)  // prints 7 because the default decimals for STR is 0 regardless of the DECIMALS setting
? STR(7.451,5,3) // prints 7.451
? VAL("7.451") // prints 7.45

Kevin,
docs say:
Specifies the number of decimal places [bold]displayed[/bold] in numeric expressions.
and I am with Antonio as Str() should never care for set decimals, as it has fixed default values, to be overriden with explicit code to give exact formating. In own code I never depend on set decimal, instead always built strings the hard way or the report writer which gives you format field control.

regards
thomas

In VFP Val() respects set("Point") too

SET POINT TO "."
? VAL("7.53") && 7.53
? VAL("7,53") && 7.00

SET POINT TO ","
? VAL("7.53") && 7,00
? VAL("7,53") && 7,53

Zdeněk

Chris wrote: ...and that brings us to a similar to dozens and dozens of similar cases we had when trying to implement VO features in X#, in a way that is compatible with VO...how would you guys suggest we should handle in X# this behavior of VFP? Try to emulate it, or make it more consistent?

Chris,
(the following not checked verified in xSharp, as Bandol 2.2 is too old IMO to give relevant info, waiting for release of 2.4a, so only vfp)

I think the parsing depending in set("Point") and prefixed $ should be fixed soon and mirroring vfp only for vfp dialect. Reason: old GIGO rule as in "Garbage In, Garbage Out", which should not happen from source or txt files fed to source. On Import/Append From similar reasoning can be applied, but IMO much less pressure: I think the practice on import I described to Karl a few days ago is still best practice and will protect against such errors if above is working - was fine glossing over implementation details in Motorola 6800 / Intel 286 and 386 days when switching between dB3+, dBMan, Clipper87 and later dB IV and FoxPro Dos.
When parsing as currency, the following comes from cast to long integer with "artificicial decimals" in vfpThe output of ? or other transformations following vfp / depending on set(s) I'd table for fine tuning at the end: there will be more people interested in nearly finished product, so probably more such inconsistencies will be fleshed out, ticketed and can be handled in 1 swoop.
Patching everything as soon as ticketed will shorten the current list, but take more total effort. At the moment I see juicier targets to implement.
To add to the mystery
If you want to try for sane behaviour - fine, but if so make that a common "xSharp" way independant from vfp or VO dialect.
But perhaps "sane" is a moving target, described by current needs and participants - I'll probably keep my Str()inging way

my 0.02€
thomas

Hi Thomas,

I agree, I think it's best to leave the numeric to string printing inconsistencies alone for now and focus on the more necessary and consistent things, like making use of the $ prefix. I have logged them though, so those are not forgotten either.

But, for when (if) we get back to the numeric to string stuff, we have already spent A LOT of time trying to imitate the quirks of VO in our current implementation of Str() and other similar functions, so will not change them again universally. If we make some changes, those will have to apply only to the VFP dialect (and possibly other dialects in the future).