Couple of items about VAL()

[Chris]

...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?

[atlopes]

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.

[atlopes]

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.

Code: Select all

SET POINT TO ","
SET CURRENCY TO "€"

m.Variable = 7.82  && correct
m.Variable = $7.82 && correct

m.Variable = 7,82  && error
m.Variable = €7.82 && error
m.Variable = €7,82 && error

[mainhatten]

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:

Code: Select all

? 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

[Zdeněk Krejčí]

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

[mainhatten]

...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 vfp

Code: Select all

u = VAL("$123,456789")
? u, "---", str(u, 20, 10)

The 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

Code: Select all

SET DECIMALS TO 2
u = 123.456
? u
u = 123.456*1
? u
u = 123.456*1.0
? u  &&& WTF?

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

[Chris]

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).