LabVIEW
Good practice: managing local decimal separator
Solved!
Hi there,
I'm maintaining a software that is delivered in different countries and I have two computers set with different regions to test it out: My own, with the LV dev + whatever exe I build; and the actual computer that will be shipped (together with some equipment) with only the .exe
The thing is, here in Germany, the decimal separator is the comma; while in the targeted region is the dot. The application must read some parameters that can be changed by our customer (and us during development time) that do make good use of the decimal separator.
It took me the afternoon to understand why my application was working perfectly fine on my machine, but providing completely wrong orbit info in the targeted PC, and obviously the culprit was the reading and analytics of some variable read from a file.
Typically, for one of the lines:
My question is simple:
How do I avoid this kind of misadventure? (Meaning having the same outputs whatever the decimal separator is)
Is this function the proper one to use? Is the Format String input correct or should I change it to something else?
Thank you in advance and have a good weekend,
Vinny.
1. You pretty much need to standardize on a decimal separator. If you standardize on the comma, that is fine. But everybody needs to use the same separator.
2. Once you have that standard, use "%,;polar shift x (rad): %f" for your format. The "%,;" at the beginning tells the Scan From String to use the comma as the decimal separator. Alternatively, you can use "%.;" to force the use of a period.
@crossrulz wrote:
1. You pretty much need to standardize on a decimal separator. If you standardize on the comma, that is fine. But everybody needs to use the same separator.
Only standardize the data that you store to the text file. Don't limit the UI so the user is only able to use a specific separator, as that will be bad UI design. So in LabVIEW, use local decimal separator (don't set LabVIEW to not use local decimal separator).
You could also determine the separator from the value-string in the file and use that when formatting from string. If you already have many files out there with different separators, that is what you may need to do.
Another place where you can get bitten is when you communicate with an instrument, which will often want a dot as separator.
I try to determine what the data is meant for respective coming from and use the appropriate format specifier for Format to String and Scan from String.
When talking to an instrument for instance the format is usually fixed (almost always decimal point). Use the “%.;” format specifier prefix.
When talking with other applications you have to find out what that application uses. With most applications, including Excel, it’s the platform specific format so you use the “%;” prefix.
Things can get more complicated when you talk over the network or read files from other sources than your local computer. If it is a proper network protocol it should document the decimal format.
If you can’t know the format for sure a method I have sometimes used is to scan the string twice with “%,;” and “%.;” prefix and compare the “position past match”. The highest value indicates which was the correct format and which result you should use.
But unless you can’t determine the format at coding time I would not use this last method everywhere! It may feel safe to do but also feels lazy to me.
@VinnyAstro wrote:
For this application specifically, there is no communication over the network, and the only devices controlled seem to have no issues with local decimal. But the only problem was reading text files that mainly are created (and tested) here, and then potentially changed by user later. So I can determine at coding time, but depending on the region we send it to it will change and I don't think that's a great idea to leave it to "oh we have to remember to change the decimal separator for this customer".
I could use this method, but I'm actually thinking of changing the interactions with these files anyway and incorporate all changes to be done in my UI directly (which would then read and write directly in the file with the proper decimal separator).
I usually handle it like this:
If the input files are created on the same computer, don't assume a specific decimal character but rather use the local format. If you do that, using no prefix AND no INI file setting to always use the decimal point or the explicit prefix "%;" (without any decimal point or comma in between the % and ; ) LabVIEW will simply use whatever is the current OS setting. This is in most cases the preferable mode because the user has set his computer for a specific format for a reason, and most applications he might use will use that local format too, especially the probably most used one for such purposes, which is normally Excel.
If the input files can come from other users from other regions, then your code should probably be prepared to handle both formats, but this is a rather seldom situation in my experience.
