This is really a big problem (for me at least)


#1

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.


#2

Cannot confirm that on my German macOS 10.12.3.

Are you not using the most recent version of Panorama X (0.1.029 build 2214)?


#3

Interesting!

I am using 0S 10.12.3 (16D32) and PanX 0.1.029 (2214).

I will look again in the localisation set up.

A.


#4

After the answer of KJM I looked into my preferences

System Preferences -> Language & Region -> Advanced

my settings were:

Number separators: Grouping: None Decimal: ,

I changed them to:

Number separators: Grouping: . Decimal: ,

(point and comma)

and now it works as it should!

This effect is not present when using Pan6.

Still, I find this subtlety quite dangerous.

A.


#5

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.


#6

"Boy, those French, they have a different word for everything!"
Steve Martin


#7

Yes,

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

Thanks for trying out.

A.


#8

Yes, I agree, this is a big problem. I’ll put it at the top of the list.


#9

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.


#10

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.


#11

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.


#12

So why is this acceptable behavior for US number format, while the same thing in a foreign format is unacceptable? It is the same problem!


#13

That was true in the past but was fixed a while ago.


#14

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.


#15

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.


#16

This is what I have been using:

Local CashAmount
GetText “Amount of Cash”, CashAmount
CashAmount=replace(CashAmount,",","")
Find Asset = "Cash"
Expand
UpRecord
Amount == Val(CashAmount)
DownRecord
Amount == Val(CashAmount)
Collapse
Field Total
Total
outlinelevel 1
firstrecord

Without the third line, the comma is a problem.


#17

Bug in the val( function, I’ve added it to Bitbucket, thanks.


#18

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.


#19

Try stripchar("1,234.56", "09..").


#20

That should be stripchar(“1,234.56”, “09,.”)
However, it will be different for different numerical formats.