bug report: %g behaves differently when used with 'Scan String for Token' for different regional settings

[allaba]

I noticed that the use of the '%g' format specifier in the operator lisr of the 'Scan String for Token' function produces different results depending on the regional setting for the fractional delimiter sign.

When '.' is used as the fractional delimiter, the function correctly identifies the tokens "find|1.23|in|this|string" when the input string is "find 1.23 in this string". However, when the regional setting is "," for the fractional delimiter, the same VI produces "find|1|,|23|in|this|string", i.e. it parses "1,23" into three tokens "1", "," and "23".  I

n contrast "%g" works correctly and independent of regional setting when used with the 'Scan from String' primitive.

The tests were made with LV 8.2 but the same behaviour exists for LV 7.1

I attach two screen shots which demonstrate the behavior:

Message Edited by ahlers01 on 01-21-2007 06:38 AM

[TomBaum]

Hi ahlers01,

When you want to use 'Scan from String' VI to read out numbers the standard format specifier for separator characters depends on your local settings. If you want to read out numbers with separator characters which don't agree with your local settings you have to overwrite the format specifier. For reading numbers like 1,23 use the format specifier '%,;%g' and for 1.23 use '%.;%g'. You can also look this up in the LabVIEW help topic Format Specifiers Syntax Elements.

When you use 'Scan String for Token' VI the standard format specifier for separator characters is '.'. If you want to read out nubers like 1,23 you have to overwrite the format specifier (operator), use '%;%g' for both types of numbers. Otherwise you use the format specifier like shown above.

Regards
TomBaum

[allaba]

Thanks for the feedback, Tom!

But I guess I didn't make my point clear. What I complain about is the inconsistent behavior of the 'Scan String for Token' function. I know that I can use the %,; format specifier to overwrite any separator settings. But that's exactly want I do not want to do. I want (and expect) the same behavior when the WindowsXP setting is . for separator in one country and when it is , for separator in another country. With the present behavior however the 'Scan String for Token' function would find 1.23 when a user in the US enters "1.23" as part of the input string, but it would not find 1,23 when a user in Germany enters "1,23" as part of the input string. The 'Scan from String', in contrast behaves correctly, it converts to the correct numeric in both countries.

regards
Franz

---

@TomBaum wrote:
Hi ahlers01,

When you want to use 'Scan from String' VI to read out numbers the standard format specifier for separator characters depends on your local settings. If you want to read out numbers with separator characters which don't agree with your local settings you have to overwrite the format specifier. For reading numbers like 1,23 use the format specifier '%,;%g' and for 1.23 use '%.;%g'. You can also look this up in the LabVIEW help topic Format Specifiers Syntax Elements.

When you use 'Scan String for Token' VI the standard format specifier for separator characters is '.'. If you want to read out nubers like 1,23 you have to overwrite the format specifier (operator), use '%;%g' for both types of numbers. Otherwise you use the format specifier like shown above.

Regards
TomBaum

---

[Marc_A]

Actually it works exactly how you want it to if you just don't wire %g as an operator. With no operators it doesn't try to format 1.23 or 1,23. It treats them the same and tokenizes them just fine. You would only need to add the %g if you used ',' or '.' as delimeters. Maybe you do in the program that you're writing and that's why you need the %g.

[altenbach]

I also agree that you don't need to define any tokens because you have delimiters in place. 🙂

If the string were "find1.23in string" (notice no delimiters around the number!), a %g on a US computer will still produce the desired result (see image), but will fail with a string input of "find1,23in string". Unfortunately, it seems we cannot switch the decimal seperator with a token of "%,;%g", the number will no longer get recognized and we only get two elements in the output ("find1.23in" and "string").

Somebody would need to test on a computer set to "," to see how things work.

It would be great if the token string would accept switching with "%,;" and "%.;", respectively. 🙂 (there is always the product suggestion center;))

Message Edited by altenbach on 01-25-2007 01:26 PM

[TomBaum]

Hi,

on my mashine (german XP) it works in both ways like you expected. You can see it in the added picture.

[altenbach]

Read my post again.

Obviously it always works if you have seperators around your number, "space" in your case. I would expect that it no longer works in your case after you remove the spaces around the number, the only situation where a token should make a difference. 😉

Look carefully at my example (the text is "find1.23in string", not "find 1.23 in string"):

[TomBaum]

Hi,

your are right, I did not recognize the missing seperators. If you write a text like "find1.23in string" LV did not give you the result you expected.

But ahlers told about another problem and he got delimiters, so it works in the way I described.

Regards
Tom