See picture of a brand new DB in panX (no procedure at all). Note that decimal separator is , because of my localisation of OSX.
In bottom record 4, I entered 1000,00 in field B, then duplicate record to get record 4 up. Surprise, 1000,00 becomes 1,00. Then I copy each cell B of the two records to create cells C, and again 1000,00 becomes 1,00!
Same behavior for the following records. Surprisingly up to 1000, there seems to be no problem. This could be connected to the thousand separator that in my case is suppose to be . due to the localisation.
I mentioned that already once, to no avail. This must be corrected quickly as this is very dangerous if not spotted in time.
I tried it with the region set for France. With the default setting for that region, grouping was space, and with that setting I could duplicate the problem. When set for none, or period, I could not.
you are correct. I looked on another computer, (preferences untouched).
The default setting with region set for France is: Space and comma.This creates the problem as you point out (and not with None and comma as I wrongly reported).
I forgot to mention – this is a really really big problem because it shows up even when simply editing a numeric field, or importing text. The good news however, is that I just fixed the problem, so the fix will be in the next release.
Fun fact – Apple is using a non-breaking space (option-space) in this situation, not a regular space. So that had me confused for a bit. Extra good news – now Panorama will ignore whitespace in numbers no matter what settings you are using.
I want to reiterate that this is not something that only fails with foreign formats. If I input 1,234.56 into a cell, Panorama reads it as 1.00. I have a custom function in Panorama 6 which corrects that, but I have not been able to make it work in Panorama X.
If you set a numeric field or variable to the value 1,234.56, Panorama will correctly interpret the comma as a non-numeric and will stop reading digits. Remove the comma and all will be well.
It’s not the same problem. In a European-style format, the comma and period are interchanged (and sometimes a space replaces one of them) so that a period thousands separator is interpreted as text and a comma decimal point is not.
Think of US-style dates vs the rest of the world - where I live, 30/6/1937 is my date of birth - if I lived in the US, it would be 6/30/1937. Panorama is very adaptable - I have no doubt that, when the little green men arrive from Alpha Centauri, Jim will whip up date and number formats that suit them.
It seems that “1,234.56” can be typed into a cell and it will be 1,234.56, but if you use a dialog like GetText and input “1,234.56” it will be placed in the cell as “1.00” in either version of Panorama.
I have been copying numbers in that format and trying to input them from a dialog, and the result is as I said. I have had to convert the numbers by removing the commas.
Similarly, using striptonum(“1,234.56”) gives 123456. I suppose this could be what it should be, but I would really like some other strip function that would give 1234.56. It would really simplify my stock quote procedure.
