ineffective "localized decimal point" setting

[christian_w]

In my LabVIEW program I call an interop assembly that calls (among other processing)  the wcstod function to convert a string (no LabVIEW strings) to double.

If I run my main VI in the LabVIEW development environment the call of wcstod fails due to a localized decimal point. The LabVIEW executable runs fine.

I read all the threads here about the settings in Tools - Options - Front Panel "Use localized decimal point" but that doesn't solved my problem. My LabVIEW code is not processing any strings.

For me it seems as there's no way to tell the LabVIEW development environment not to use the localized decimal point in the VC++ runtime.

To solve that problem I have to call setlocale(LC_NUMERIC, "C") explicitly before calling wcstod in my C++ code or change the locale settings in Windows.

I work with LabVIEW 10.0.1

Why is this Tools - Options - Front Panel "Use localized decimal point" setting not effective in this case ?

Best regards

Christian

[LamD.]

Hi christian_w,

The "Use localized decimal point" does only work for LabView strings.

Since you're not using LabView strings and passing them, the setlocal() is responsible for the string.

Best regards

Lam

[christian_w]

As I wrote, I suppose the LabVIEW development environment uses the localized decimal point with no option to suppress that. In my case it's a comma (German). That behavoiur is different from the LabVIEW runtime executable were the point is used.

From my point of view both LabVIEW environments ( dev and rte ) should act the same way.

Native english or american users will probably never see this problem.

Christian

[cpede]

I fully agree with Christian.

I'm from Denmark, and we also uses "," as decimal separator.

I recently wrote an ActiveX/COM driver, and It worked perfectly in C++/C#/VBScript etc. but when run with LabVIEW, all kinds of problems occurred. Finally we discovered that my internal MFC string s using CString formatted with the CString.Format (same as sprintf) converted numbers with the "," as separator causing every command expecting an "." to fail.

Of cause you can say that this should have been checked, but this is the only application causing this problem. And we also tried the setlocale(LC_ALL, "C");, but it has to be included in a lot of DLLs.

-cpede

[rolfk]

The C runtime library setting is a per process setting. LabVIEW being its own process has every right to call setlocal(), which it does during initialization. That this can break libraries you call in LabVIEW is not the fault of LabVIEW. A library assuming a certain locale is basically at fault. It can’t assume a specific local when called by a program. The problem is caused by the C Runtime library of implementing a process wide local setting. It’s also the reason why the C runtime library often provides additional extended functions such as wcstod_l(), which take an explicit local parameter. 
Your library calling setlocal() as fix has the potential to break LabVIEW functions and is at your own risk!

[wiebe@CARYA]

---

@christian_w wrote:

Why is this Tools - Options - Front Panel "Use localized decimal point" setting not effective in this case ?

---

This setting is not applied automatically to the executable.

You have to add the key to the ini file of the executable.

Not sure if you did this, nor if it applies to .NET, but won't hurt to check.