I am using a French localised OS, with the comma as decimal separator.
When I import a DB from Panorama6 into PanoramaX, all work well. The numbers (with two digits) are shown as 12,34 as expected and the formulas work well, running total for example.
However, If I want to enter a new value, 12,34 for example, the comma (or the . for that matter) are not active and I enter 1234,00.
Thus, I can enter 12 then I get 12,00 and I can correct directly in the cell, modifying 00 to get 34, and thus finally 12,34, and I am back in business.
When I do info("decimalseparator »), I do get the comma as expected.
I tried to play with the Output Pattern, in the Field Properties to no avail.
I cannot duplicate this, it works fine in my tests, and others are using it with this format with no problems. Here is a screen shot. In this shot I just successfully entered 12,34 and 234,56.
I noticed on the language & region you posted above there is a category for First day of week. (Never saw that before, since I didn’t look). Is there a way to make PanX respond the same way, using a select item? I saw where there was a workaround by doing some coding. I guess I am wondering why Pan X doesn’t follow suit with selecting Monday. When I use the following code:
removesummaries "7"
selectall
Field "Date"
Groupup by Week
Field "Mileage"
Total
CollapseToLevel “1”
the week starts on Sunday. My week starts on Monday…
Interesting issue. I was going to reply that Panorama uses Sunday as that is the programming world’s standard. The US standard is Sunday.
Personally I am an ISO fan. It is interesting the latest ISO 8601 standard does in fact state that Monday is the new standard. The ISO 8601 was defined in 1988.
The previous ISO 2015 standard, defined in 1971, did have Sunday as the first day of the week.
I also never noticed that the first day of the week could be changed, and no one has ever mentioned this or complained. Still, I’ll add it to the list of things that would be nice to do at some point.
Wow, another thing I had never noticed about this panel – the fact that you can set multiple languages. I think that might only be for spell checking though – what else could it be for? You obviously can’t have things like menus in more than one language at a time.
There is also an Advanced panel, which I think has the final say. I just used this to set the number separator to commas even when the language is set to English. When I did this, Panorama X correctly handled commas in numbers, at least on my system.
I hope the mystery on your computer can be resolved.
Jim, you can have several languages to choose from, but only one – the topmost – language is used as the active system language. You can drag the languages to change that, and all applications that are launched afterwards will use the new topmost language. You have to restart the Mac, if you want the entire system to use the new language.
Hmm, but I notice that it says preferred languages, not regions. So I think you can have multiple languages but only one selected region? And probably languages have nothing to do with what the current region is? Yes – I can change the region all I want but that doesn’t change the language.
So I think the language selection has nothing to do with numeric separators. The puzzle is, why aren’t commas working for @aherve? It looks like his settings are set so that commas should be treated as decimal points.
The comma is – according to Alain’s screenshot – correctly set as decimal point.
Any possibility that the other setting – the thousands separator – is the culprit? (It seems that the France & French region & language setting uses empty spaces as separator.)
I did some experiments, and I found that the problem is in fact not connected to localization at all.
If I create a brand new DB in PanX, using part or the original DB, all is working well, and the comma is properly active and displayed. Thus all seems OK on this side.
At this point I have concluded that the problem appears during the conversion from my DB in Pan6 to the DB in PanX.
It appears that Apple lets you set any day as the first day of the week, so if I follow Apple’s setting it should be good anywhere.
One thing I’m not sure about is the dayofweek( function. Should it change depending on the setting? That might break existing code. Maybe create a new function that respects the system setting for first day of the week? (Of course either way I would also create a function that would allow you to find out the system setting for first day of the week.)
It would seem that if you went with Apple’s ‘First day of week’, for all US users, it would not break existing code as Apple’s default for Region: United States is Sunday.
User could change that to Monday if they were ISO fans and you would then be respecting the user’s choice. A new function would allow for Panorama to operate different than Apple’s setting.
Are there any upcoming Panorama preference settings that this might fall into?
Sure, it wouldn’t break any code for anyone in the United States. But what if someone in another region had code that assumed that dayofweek( was zero for a Sunday?
Anyway, I think I may know a way to handle this so that it won’t be a problem. Stay tuned.
I was talking about a formula that uses the dayofweek( function. There is no way for you to customize how group works, that is a change I will have to make.
