I have encountered a problem where I need to know if Windows on a client uses decimal points or commas. I have been looking through the MBS Components and searching the internet, but I have not found any solution. (It could be that I am from Sweden and don't know the correct terms to look for).
The scenario is like this:
I have developed a solution on Mac using Swedish and, thereby, with decimal commas.
When I deployed on a Windows server with Windows clients, parts of the solution started to behave strangely.
After some debugging, I found that FileMaker still used decimal commas, as it should have, but the Windows OS was set for US format with decimal points.
Without getting into details on why this matters, I am looking for a way to determine what decimal separator the Windows OS is set for. Can anyone help me with this?
I can add that my customer is a Swedish company residing in Sweden but with English as the company language. Therefore, all computers are installed with English versions of Windows, while numerical and date forms in FileMaker are set to ISO standards.
As a more independent option, if you want a more programmatic independent way to determine current locale, I would recommend creating a simple and free REST service in Java.
The code below is a programmatic API-way to get the information you want for the "current locale". This code could be called by other applications as well (browser, other programs, ....).
DecimalFormat df = (DecimalFormat) DecimalFormat.getInstance(Locale.getDefault());
char separator = df.getDecimalFormatSymbols().getDecimalSeparator();
System.out.println("The decimal separator in the current locale is: " + separator);
You wouldn't use the "System.out.println()" in a REST service, but instead just use a RETURN statement to your FileMaker INSERT FROM URL's "Target" field setting.
Thank you, @mipiano, but my problem is that FileMaker uses decimal commas while the Windows OS is set for decimal points. So, your suggestion would always return a decimal comma in my case. On the other hand, I like your approach and will use it as a fallback for FileMaker.
Thank you, @OliverBarrett, and this, I think, is just what I was looking for. I will try it out, and since I am using the MBS plugin, I will see if I can run it through it.
I think using the MBS "Shell" command would work for you where you could run a
".class" file from the command line using "Java compiledProgramName". Note, you'd have to pre-compile the Java code first.
A REST approach, on the other hand, frees you from "FileMaker Only" and is totally free forever. You can also call the same code from other programs--even the browser.
We often have this problem in Quebec. The operating system in one language and the solution in another. Some systems use the dot, others the comma, whatever the language. I've been looking for a long time to find out which decimal separator the OS uses. I haven't found a simple, reliable solution. You can find the Filemakeer decimal separator, but not the OS one. I've looked at the problem from another angle. I'm making sure that the numbers entered are correctly entered into FileMaker. The user can use the dot or the comma, it doesn't matter anymore.
I use a custom function.
The function receives the number and separates it into 2 parts. The integer part and the decimal part. Then it adds them together. At the end, the number is always in the right format for FileMaker.
It handles 3 decimal separators: the point, the comma and the Momayyez.
/**
uNumb_00GetAsNativeNumber ( numberToConvert )
Convert a foreign number to the native number of the FileMaker file
decimal separator : comma (44), dot (46) and Momayyez (1643)
by : sylvain.parent@gmail.com - 2020.04.16
Version : 1.0
**/
I'd be curious to know if this matter could be solved via the Get( SystemLocaleElements ) function, noting that this is distinct from the Get( FileLocaleElements ) function. I haven't ever used the SystemLocaleElements function, but it appears to offer what is needed in this case.
Also a +1 for parsing the result of a simple arithmetic expression when the need is to obtain the FMP file's decimal separator.
Get (SystemLocaleElements) is unfortunately not the sure bet answer.
Note that I know what I write here to be true when using FileMaker Pro 19 or 2023 in MacOS Sonoma. Things could be different in different versions of the client, in different clients (WebDirect, for example) or for Windows or Linux. Note also that locale settings in MacOS apply to user accounts, not to the OS itself.
In MacOS, Get (SystemLocaleElements) returns the settings according to the default language for the FileMaker Pro application. This can differ from the locale settings of the user account. It is possible to specify a default language for each application in MacOS that differs from the user account's default language.
FileMaker will faithfully return the system's locale settings if the application's default language is the user account's default language.
FileMaker will return some other locale settings if the application's default language differs from the user account's default language. What are these settings? Unsure! What I see on my computer are a mix of my user account settings (unmodified Canadian French) and other settings (FileMaker Pro is set to default to the English language). The function returns a Frankenstein date format corresponding at times to my user account settings (2024-01-31) and at other times to an English format (January 31, 2024), and returns a number format that corresponds to the regular Canadian English numerical format (1,234,567.89).
The custom function unfortunately doesn't handle many numeric formats that exist (try "1,000,000.00"). Would a user enter the thousand separators during data entry? Likely not… but pasted or imported values are more likely to contain them.
You could alternatively specify that a field must contain a numeric value only (field validation > strict data type > numeric only) and let the user handle the errors.
This is not the purpose of the function. It doesn't convert. The function's main purpose is to enable a user to enter an unformatted number with a decimal separator such as a point, comma or Momayyez, and be sure that the number will be in the correct format in FileMaker. For formatted numbers such as 1,000,000.87, it's unfortunately not possible to convert them. At least I've never found a reliable way of doing so. To convert, you need to check whether there is more than one decimal separator in the string. If there is, you can't convert the string. The advantage of French formatting is that the group separator (space) is not a decimal separator, so it can be eliminated.
Last November I wrote a Custom Function that should recognize inputs with thousands and decimal separators and convert them into the system format. However, there are small limitations where you have to be careful.
If you are interested ...
The CF only treats periods and commas as separators. I only learned today that there are others.
I know, the name of the CF is as long as the contents of a book. But I haven't found a shorter one that halfway indicates what the thing does.
@fragonlesec is right in saying that there is no reliable way to parse a string representation of a number if only one grouping character XOR radix character is present and the string locale is unknown. For example, "1,234" could mean one thousand two hundred and thirty four or one (the integer) comma (the radix character) two three four (the fraction).
Things change if you have one or multiple grouping characters XNOR the radix character in a string representation of a number. For example, "123456", "1,234,567", "1,234.56", " 1'234,56" and "1 234,56" can all be parsed without knowing the strings' locale.
That was an interesting aspect and solution @bdbd ; I love articles like that. I haven't read that one before since, so far, all my customers have only been using ISO standards.
I am so happy you took the time, @fragonlesec, to write this answer and supply the CF. As I told @bdbd, I love learning about things like this, even though I, during my over 30 years as a full-time FileMaker developer, have never run into this problem. I am so grateful that most of Europe uses the ISO standard since this must be a real headache to handle this scenario!
I see your point, and I only have to handle two special cases: decimal commas and decimal points. We, too, use space as the thousand separator (ISO Standard), which, in many cases, can lead to a line break in the number since it isn't "connected". I guess you too have run into this problem
