Modify country parameter by program

[Bobillier]

Hi

I want to know if there is a way to modify windows country parameters by program. And especially "," (virgule in french) by "."

[Rolf Kalbermatter]

QUOTE (BOBILLIER @ Mar 23 2009, 01:14 PM)

Hi

I want to know if there is a way to modify windows country parameters by program. And especially "," (virgule in french) by "."

MSDN is your friend. But if you intend to write an application for other users that is going to overwrite their preferred system settings you are going to annoy most of your users big time. A program trying to mess with my system is going to be uninstalled in a matter of seconds never to be looked at again, no matter how nice it is.

Rolf Kalbermatter

[Bobillier]

Yes I know. if i modify it others will be too. But in my case, i must modify trully because the data (numeric) generate by my application are analyse with another software who don't want ",". And in fact now, i manually modify the country parameters to solve that. And like sometime i forgot to do this, i want place in my program, a function who do that .

Perhaps by windows API ?

Eric

[Rolf Kalbermatter]

QUOTE (BOBILLIER @ Mar 23 2009, 05:13 PM)

Yes I know. if i modify it others will be too. But in my case, i must modify trully because the data (numeric) generate by my application are analyse with another software who don't want ",". And in fact now, i manually modify the country parameters to solve that. And like sometime i forgot to do this, i want place in my program, a function who do that .

Perhaps by windows API ?

Eric

So what speaks against making your LabVIEW application work in the format that the current user is using? LabVIEW's string conversion function give you every power to do that. If you know you need to deal with decimal point (for instance instrument communication) then disable the "use system decimal point" input at the string nodes or prepend %.; to all format strings for Format into String and Scan from String.

If however you write out data to disk or whatever, such as a spreadsheet file to be read by the other application then just leave it as is and LabVIEW will use whatever is the current user setting for the decimal point. Don't try to outsmart your end user. They seldom can appreciate that .

Instead make your application work as best as possible in the environment your users work. It may seem like a lot of a hassle to do what I explained above and after the fact it can be indeed quite a bit of work. But once you stick to this rule it does in fact not cost you any more work as it will get second nature to consider at all string formatting places if you do need a specific format or instead want to go with whatever the user has currently selected. It always depends who will be the other device/application dealing with the data.

Rolf Kalbermatter

[RalcoBe]

I had the same problem.

Including excel files to read, coming from different pc's (some "." other ",")

Then communicating with different RS232 devices, some read both "," and ".", some not.

What they write was for some ".", for others ","

I made 2 subvi's: commatopoint.vi and pointtocomma.vi, with strings as in-and output.

Strings because that's the way RS232 speaks and listens, and it's the in-output of the excel files.

I made them myself (don't know if they exist) to better handle exceptions.

.

[Antoine Chalons]

[...]

disable the "use system decimal point"

[...]

On a french version of Windows, I strongly recommend to disable this option just after you install LabVIEW.

There are at least 30 threads on the french section of NI Forums for which the solution was this.

[Rolf Kalbermatter]

On a french version of Windows, I strongly recommend to disable this option just after you install LabVIEW.

There are at least 30 threads on the french section of NI Forums for which the solution was this.

I actually leave the global system setting in LabVIEW alone and program on LabVIEW function level explicitly. If you know an instrument will send decimal point then set the scan from string and format into string to explicitly use that format instead of relaying on the user to have his system setup accordingly. Because if you work with multiple instruments and systems at the same time you will be switching the settings back and forth continuously.

If you operate on user data, such as files coming from the system let it work by default with the system settings, because most applications having created that file will also use that setting. Of course if you get input from files or such from a different system all bets are off, and you will need to define a certain standard. You also can make the parser smart but that only works so far and gives sooner or later ambiguous results.

[Black Pearl]

In germany you have the same issues, and I always change the country settings to US. But then if you create a new user (even worse if the customers are doing this), it might show up as DE again. A lot of software and hardware isn't localized, and I really don't want to care about it. On the other hand, Excel is localized to an incredible amount. All the functions for the spreadsheet are localized! If you do any advanced thing with it via ActiveX from LV, this is unmanagable...

Felix

[Rolf Kalbermatter]

In germany you have the same issues, and I always change the country settings to US. But then if you create a new user (even worse if the customers are doing this), it might show up as DE again. A lot of software and hardware isn't localized, and I really don't want to care about it. On the other hand, Excel is localized to an incredible amount. All the functions for the spreadsheet are localized! If you do any advanced thing with it via ActiveX from LV, this is unmanagable...

That's why I leave the system settings alone. If you know what to expect as numeric format when you get some numeric strings from somewhere, program in LabVIEW explicitly to that format instead of relying on the right system settings (which as you have found out can suddenly change without you knowing).

When you know it is system dependent, as basically anything that comes from Microsoft is, and any programmer relying on MS libraries somehow, then do so in LabVIEW too.

If you don't know, do a good guess which probably will be most times to be platform format.

Last but not least when you write files that are meant for your application only, always write them in a fixed format (either always decimal point or always comma) unless the customer specifically asks otherwise. That way you can exchange data files between different installations of your application without having to worry about system settings either.