double - forced localization?

Getting Started
1

I have a strange problem with variables of type double. The variables seem to have a comma in the written representation. Also in the Debugger. If I run:

dim d as double
d = d + 0.1
break

the debugger shows: “0,1” as common in some countries, but not the point as I am expecting (“0.1”). If I change the value in the debugger I have to use the comma; the decimal point is ignored.

I was looking to the representation of doubles because I have a problem with ARGen. I got an exception because the format given for a double variable was with komma instead of the decimal point.

I use a german system with Windows 8.1 - on my Mac it’s the same.

2

Yes, the debugger shows floating point values localized. Stupid. IMO you should file a Feedback request.

3

That sounds like two completely separate issues. As far as the debugger goes, it should show the localized values. ARGen is a different problem. Have you reached out to BKeeney Software?

4

The debugger should not show the end user value (=localized), but the internal value (= not localized) – personally I think this is wrong as wrong can be.

5

To the debugger, you are the end user. So it should definitely be localized.

6

So is the source editing in the IDE. So why will this not compile?

Dim d As Double = 1,234

Really, that is as silly as storing localized values in a database. The developer always should see the “raw” value.

7

Those are two completely different things. Putting localized values in code is like storing localized values in a database. Definitely the wrong thing to do. Displaying values in the debugger is live interaction with an end user. I do see your point about the inconsistency, but I wouldn’t call it blatantly wrong. In any case, file a bug report / feature request.

8

Just checked: both XCode and Visual Studio show non-localized doubles in the debugger.

9

@ Tim Hare

I am still checking why ARGen doesn’t work as I exspect it to work.

The error from ARGen was that the double had a format the database didn’t accept (a number with “,” instead of “.” in a double)… In the debugger the double had a “,”. As I know now that’s an information without any value because the debugger shows the localized values.

Before I contact BKeeney software I will try to solve the problem by myself.

For me the forced localization is a bug because I don’t see the “real” things my program deals with. You can see that my problem why the database refuses the values because of wrong format is hidden by the localized representation. At least my problem is more difficult to solve as if I had a correct representation of the values as “seen” by the program itself.

10

The “real” value in your case is the value being passed to/from the database. It must be being passed as a string, since a true double value wouldn’t have any formatting at all. So the real value you are concerned with is the value of that string and how it is being created, not the value of the double variable and how it is being displayed.

11

IMHO the debugger being about code, it should have the same representation as the code editor to avoid possible confusion.

I suspect the Xojo engineers did not notice that discrepancy because they use US English locale, which is the same as code.

Same thing for ARGen.

As Norman would say, localization is a lot of fun :stuck_out_tongue:

12

The problem is that the string sent to the database contains the value with a komma instead of the decimal point (“42,5” instead of “42.5”) . So the database (postgresql) sends an errormessage.

Not the solution, but a (quick and dirty) workaround:

In BKS_ActiceRecord.PostgresSQLDatabaseAdapter.BindValues I am checking whether the value is a double and if yes I use a helper variable of type text. So the string sent to the database is (for example) “42.4” instead of “42,5”.

.

dim pi as Introspection.PropertyInfo = oField.piFieldProperty
dim v as variant = pi.Value(oRecord)
if v.Type = variant.TypeDouble then 
  dim es as double = v.Doublevalue
  dim help as text
  help  = es.ToText
  stmt.Bind(i, help)
else
  
  stmt.Bind(i, v)
end if

I don’t know. Is it a problem of xojo because I use a german system (we use 42,5 instead of 42.5) or is it a problem of using a variant (or a combination of the two) or am I too stupid to use avtiverecord?

13

Where is that string coming from ?

At any rate, it is probably just as simple as

thisGoesToTheDatabase = Replace(StringWithComma,",",".")

I do not think the problem is the variant. Most probably it is because in German, as well as French locale, the decimal separator is comma.

14

@Michel Bujardet

Where is that string coming from?

The original code - used for sql-binding - is:

dim pi as Introspection.PropertyInfo = oField.piFieldProperty dim v as variant = pi.Value(oRecord) stmt.Bind(i, v) end if

It could be done with string.replace. Perhaps the way with text is a litte bit more localization-independent? I don’t know.

15

Ah. It’s a problem with Variant. I think your solution of going through an explicit Double-to-String conversion is the right way to go. You might use String and Str() instead of Text and ToText. Make sure you report it to BKeeney.