I changed the region configuration on my computer to "Dutch (Germany)" and it behaves as you mention. So, indeed it is a bug. The fix could be one of two: 1) Use regional settings when assigning literal values to variables but store them internally in a standard format (e.g. a dot); this way other programmers can view the source code using their own regional settings (e.g. a comma), or 2) Don't use regional settings when assigning literal values to variables and standardize on the dot as the decimal separator. I think the first one might turn out to be too complicated, like when passing literal values as arguments to functions because they need to be separated by commas. The latter seems to be the right fix.

haha, Ricardo, I'm "Dutch" and that's definitely not Germany. Germans are "Deutsch" and Dutch are from Holland.

(sorry, I know it was probably a typo)

And yes, your number 2) is I think the best thing to do. In code, I've never assigned "," as a decimal separator for hard coded values. Unless you might be working with strings and decimals. I think decimals do look at the language settings (when working with strings in combination), but all other values need a dot, no matter which language setting.

regards

Hahaha, you are right. I should have put "German (Germany)". I work with some german customers and I knew that German in German was spelled differenty. But in English it's actually "German". No need to translate. :)



I checked with VB.NET and a dot is always used no matter what regional setting I use. I guess that's a standard in all programming languages.

Sorry, I meant PB 2019 R2, not R3. Then, I tested it in PB 2017 R3 and it also works fine.

Both expressions should result in 2500.

25E2 is 25 * 10^2 equals 2500

2.5E3 is 2.5 * 10^3 equals 2500

Hi Ricardo ... FYI: Yes, OK on my 2017R3 build 1915 as well.

I think Ricardo is right: they should evaluate to 2500, at least on my calculator ?