Retrieve Language setting of your OS through Labview

[willy]

Dear All,

This is Willy from AUS. Waving my hands towards you all.

I recently have encountered a strange problem. I developed a user interface by Labview 7.0. Then I convert it to an executable file. When it was installed at our customer end, they found they cannot control the device properly. However, it works perfectly at my side. Then I finally figure out because their language setting is French instead of English. It makes me wonder if I can seek OS language setting information through Labview and display a pop-up window to remind our cusomter to change their language setting if it is not English before they launch our GUI software.

Do you guys know how to achieve that?

Thank you all indeed.

[Mike Ashe]

Go to the MSDN search tool at Microsoft and search on "OS language setting(s)". You will probably find that there is a Windows API call in either user32.dll or kernel32 that will give yo what you want. Once you have the function call parameter just use the LabVIEW Call Library Node to make this call. Another option is to use .NET calls to the Windows Scripting Host for the environment. Lastly, there is probably a registery setting that you can quiry using LabVIEW's registry VIs. There's three possible ways.

Cheers

[Michael Aivaliotis]

Dear All,

This is Willy from AUS. Waving my hands towards you all.

I recently have encountered a strange problem. I developed a user interface by Labview 7.0. Then I convert it to an executable file. When it was installed at our customer end, they found they cannot control the device properly. However, it works perfectly at my side. Then I finally figure out because their language setting is French instead of English. It makes me wonder if I can seek OS language setting information through Labview and display a pop-up window to remind our cusomter to change their language setting if it is not English before they launch our GUI software.

Do you guys know how to achieve that?

Thank you all indeed.

Usually this language problem\instrument communication issue is solved by adding the following entry to you executable ini file:

useLocaleDecimalPt=False

[i2dx]

This is Willy from AUS. Waving my hands towards you all.

wellcome

It makes me wonder if I can seek OS language setting information through Labview and display a pop-up window to remind our cusomter to change their language setting if it is not English before they launch our GUI software.

Do you guys know how to achieve that?

the information you need, is in the registry. I can remember that an ex.coworker wrote an utility in LV to extract that information for exact this purpose you mentioned. I will try to catch him today and ask him, if he can give me the code!

[jpdrolet]

Usually this language problem\instrument communication issue is solved by adding the following entry to you executable ini file:

useLocaleDecimalPt=False

Like Michael said, it is probably a decimal point problem. The device and application probably expect to receive number strings using a point. While forcing the application to use the decimal point (useLocaleDecimalPt=False) is a quick workaround, the user still might prefer to see the comma in the interface.

The best way to make your application independant of the local decimal separator is to set the decimal separator in the format strings of the application when communicating with the device. When scanning, formatting strings to/from numbers, prepend all format strings with "%.;" e.g. "%.;%.3f %.2f".

To determine what is the decimal separator in use on the machine, convert the number 1 with "%.1f" and check the second character (decimal separator) of the resulting string.

To determine the language, an easy way is to convert a date to string with the format %A which returns the full weekday name. Check if the weekday name is in the French set ("dimanche","lundi",...) or English set ("Sunday","Monday",...) (I'm not sure of the capitalisation).

[didierj]

It makes me wonder if I can seek OS language setting information through Labview and display a pop-up window to remind our cusomter to change their language setting if it is not English before they launch our GUI software.

As jpdrolet indicated in his last post and to my opinion it is a bad idea to force the user to change local computer settings. It will have much more impacts, since he won't using his computer just for your app (I assume). Your coustomer will "not be amused" if he has to change such settings (by the way, maybe he might not know how to do it at all).

- Let the user write/read to numeric controls (not strings) where applicable.

- convert user string-inputs to values using localized decimal point.

- convert values to strings for parameter save (e.g. in an ini-file) NOT using localized decimal point.

- Where applicable use timestamps as "seconds since ..."

Didier

[willy]

As jpdrolet indicated in his last post and to my opinion it is a bad idea to force the user to change local computer settings. It will have much more impacts, since he won't using his computer just for your app (I assume). Your coustomer will "not be amused" if he has to change such settings (by the way, maybe he might not know how to do it at all).

- Let the user write/read to numeric controls (not strings) where applicable.

- convert user string-inputs to values using localized decimal point.

- convert values to strings for parameter save (e.g. in an ini-file) NOT using localized decimal point.

- Where applicable use timestamps as "seconds since ..."

Didier

Yes, I think you are absolutely right. And as you all know it is caused by the decimal problem. I believe I've got to write a program to look after this. Have tried the way Michael had suggested, still sending the string with comma instead of dot, it caused confusion for our firmware. :-)

B.T.W, sorry for this late reply. Lots of things going on at this moment. And your help are really valuable and highly appreciated.

Willy

[Rolf Kalbermatter]

Yes, I think you are absolutely right. And as you all know it is caused by the decimal problem. I believe I've got to write a program to look after this. Have tried the way Michael had suggested, still sending the string with comma instead of dot, it caused confusion for our firmware. :-)

The right way to deal with this is as JP Drolet has explained. Use the Format Into String function with the .; prefix anywhere you need to send decimal point strings. This way you do not rely on an ini file settting that can be hard to maintain for distributed applications.

Where user interface things are concerened (or file output that is to be interpreted by other applications such as Excel) just use without prefix so that the user gets the format to see that he expects. For entry fields you should try to use the native datatype controls as much as possible. A numeric control has the logic to deal with platform specific user input and so does a data/time control. Trying to deal with this on your own is an exercise that needs LOTS of time.

Rolf Kalbermatter

[behzad]

wellcome

the information you need, is in the registry. I can remember that an ex.coworker wrote an utility in LV to extract that information for exact this purpose you mentioned. I will try to catch him today and ask him, if he can give me the code!

Hi

You can see your local language in this area of registry

HKEY_CURRENT_USER\Control Panel\International\Locale =00000409

Or

HKEY_CURRENT_USER\Control Panel\International\sLanguage = ENU

and so for the french must be :0000040C

Have good time

Behzad