incorrect variant to double coversion from Excel with Eurpoean language

[pauldavey]

I apologise for not having code to post right now - I will do that from work tomorrow. But there is a previous thread that describes the same issue that I just found:

http://forums.ni.com/t5/LabVIEW/Wrong-result-after-convert-variant-to-double/m-p/953419

I have a compiled LabVIEW program that runs just fine on an English-language computer - it loads floating point numbers from either (European-formatted) CSV files or Excel xls(x) spreadsheets, communicating with Excel using ActiveX in both cases.  What I see is exactly what is seen in the above thread - the Variant values are displayed on the Front Panel with the Decimal point, but when you convert the variant array to a double array, the number is interpreted incorrectly and the decimal separator is ignored.

In otherwords if the Excel file had a value 4.556 (which is formatted as 4,556 in the European files), a Variant Indicator on the front panel displaying the value would display "Value->4.556E+00", but if you then convert it to a double, it would be interpreted as 4556 (or 4.556E+03) (4 thousand 5 hundred and 56).  The LabVIEW program is using the European locale settings for displaying other floating point values on the front panel.  It seems that LabVIEW is forgetting to use the Locale settings in the Variant->Double conversion (or some other inconsistency).  Why does it display it ok in the Variant Indicator, but then get mis-interpreted?

[jcarmody]

What?

So sorry, my screen isn't large enough to read your post. 

[tbob]

Maybe the OP has eye trouble and needs to have BIG font in order to read.  I knew a guy with retinal damage, and he had to use big fonts.  He had no choice.  Even glasses would not help much.

@pauldavey.  Sorry I don't know the answer to your question.

[Darin.K]

I am digging it on my iPhone...

[Ray.R]

ROFL!!  Guys...

😄

Simply mention that smaller fonts should be used and let's help this person..

Sorry.. I just had to laugh, it was funny, and I think everyone needs laughter these days..

🙂

[pauldavey]

Sorry - I had trouble with a conflict between font size and web browser magnification (I pressed Ctrl Y and it all went downhill from there).  If I could still edit the post I would.  I have had trouble trying to reproduce it since I have a Windows machine using English.

[Yamaeda]

How do you convert it back? Ordinary Variant to Data? If you unflatten you'll get the decimal comma and later transforms will get messed up.

I've had some problems with outsmarting LV due to such inconsistencies which later on outsmarted me.

/Y

[pauldavey]

Hi   Yamaeda

Thanks for your reply.  I am simply using the Variant To Data function to convert the Variant (from the Value2 property of the range) to a 2D DBL array.  I have tried changing the language on my computer to German with German local settings, and everything looks German, with commas for decimal and dots for thousands (and swapping the Z and Y keys on my keyboard!).  But on my computer everything works flawlessly.  We are going to try changing the German computer to use English and see if that works.

Paul

[Yamaeda]

If the only difference is the comma/point and not thousand separators (1,000.00 vs 1'000,00) then you could try the following:

Use Unflatten variant -> (String part) Replace string 'comma to point' -> String to number with "Use regional setting" set to false.

/Y