Format string in Case structure for Scan From String function

[RJ_15]

Hello all,

I encountered an interesting concept some days ago.

In my logic depending upon some condition, I am changing the 'format string' for scanning the input string.

So I had put the format string in the case structure.

But after putting the format string inside the case or using the select statement, the output from the Scan string function is always double whatever be the format string.

I am not very sure whether I am doing correct or not; or is it a BUG in LabVIEW.

I am using LV 2009 SP1.

Thanks and Regards.

[GerdW]

Hi RJ,

it's not a bug, it's a feature...

- Please attach real JPGs, renaming a BMP doesn't change it's fileformat. Even better: use PNGs as the one attached. Do you spot the difference? Even MSPaint is able to save them nowadays...

- How should LabVIEW decide on the datatype of the scanned items, when the information of the format strings is ambigious? You will get the default and that's DBL.

- You cannot change datatypes of wires at runtime. And that's what you're trying here...

[ejkaiser]

He is not changing the data type, just the format of a string. The situation is never ambiguous. So I think one could call it a bug or at least an inconsistency.

Cheers

Edgar

[Akiel]

too a human looking at the vi it is obvious the type should be string regardless at run time. The computer is seeing a select statement which is ambiguous until it is executed. Because the compiler has determined this ip to be ambiguous it has resorted to the default. for the compiler to understand exactly what it should be we would need the labview compiler to interpret the code (effectivly run it) to ensure everything is correct and make changes to the compiled code on the fly and on each change restart the interpretaion.

Just my two cents

hope it helps 

[smercurio_fc]

It's not a bug or an inconsistency. It's by design. When you place the Scan From String on a block diagram, it has one output, and that's DBL. Also, the format string input is empty. When you wire a block diagram constant for the format string, the LabVIEW compiler will check for errors and determine the datatype at compile time. With the Select function in there, it has no way of doing that, and as far as the function is concerned, it's no different than leaving the format string input unwired, since the value on the wire cannot be determined at compile time.

I also reiterate the statement regarding the images. DO NOT CHANGE THE EXTENSION OF THE FILE TO GET AROUND THE BAN ON BITMAPS. THE BAN IS THERE FOR A REASON.

There, in all caps in case it wasn't clear the first time.

[ejkaiser]

Both cases of the select define a string. So why couldn't the compiler just come up with a string output? If this behavior is 'by design' then it is questionable design.

[smercurio_fc]

It may be a string, but it's an undefined string. Can't do something if you don't know what you're being told what to do.

[ejkaiser]

If this was the issue, Labview couldn't read strings from a text file and process them. In this case the string is also undefined at compile time.

[Akiel]

Dont forget the select, the whole point of it is the op is not decided until runtime, so this will be undefined. This in turn feeds into the next vi. Which in this case determines its op. as this ip is not defined yet the op is the default type

[ejkaiser]

Well, maybe it all comes down to the fact that in C the scanf (and sscanf and fscanf) also doesn't accept a variable as format specifier. Something I always found a bit strange and just had to accept of course.