useLocaleDecimalPt=False not working when used in shared library ini fie

[bharathp10]

Hi all,

we are using LabVIEW built shared library in one of the .Net based application. when we change the system region setting to ones which uses comma (,) as decimal separator, the string function (fraction to num) is still using the ',' as separator even after setting the useLocaleDecimalPt=False in ini file.

So, is it possible to force this setting in shared library configuration ini file?

Thanks

[rolfk]

Likely not and this ini file setting really is an ugly bandaid. This setting would change all string processing globally anywhere in the current LabVIEW process and that is almost never desired. You should program the code correctly. The LabVIEW string functions all have an option to disable local decimal point processing.

If you use the Number to Fractional String, Number to Exponential String, Number to Engineering String, and Fract/Exp String to Number function has an optional boolean input and if set to false, it will ALWAYS assume decimal point.

If you want more flexible control of the actual decimal character to use you need to use the Scan From String and Format into String nodes. There you can use these format specifiers anywhere in the format string (usually at the beginning):

%;           Use local decimal character (this is the default if no decimal format specifier is used)

%.;          Use decimal point

%,;          Use decimal comma

You can even use multiple such format specifiers in the same format string and the according function will use that decimal character until it encounters a different decimal format specifier in the format string.

Generally software should know what format is required. If you talk with an instrument, it is usually the decimal point but if you want to read a user file or communicate with an application like Excel through ActiveX, .Net, or any other IPC mechanism, you want to make sure to use the local decimal character. Telling a user he has to change his local computer setting to make Excel use the format that your borked application expects, is a sure way to annoy every possible user of your application. Most reasonably complex applications do more than one of these things and then a global setting like the INI file token is definitely NOT the right fix. As proper programming is a matter of thinking a few minutes and make the right thing, compared to try to find on the world wide web a INI hack to make the software "sometimes" do the right thing, I certainly know which option I will choose.

[bharathp10]

Hi rolfk,

Thanks for the feedback.
We need all the string functions to be using the period as separator. 

We want to force the LV assembly/process to use '.' as separator irrespective of system culture setting. so wanted to try the ini way. Our instruments are also to using the '.' as decimal separator. Yes, there is an option to use at the function level. Since the previous version of the application was using the ini parameter we wanted to try the same. Only difference is previous one was exe and now we are working with .net assembly. If ini method doesn't work, we'll go ahead with changing at the function level.

Thanks