Scan From String changes output type when wired through case frame

[max_]

hello,

I want to convert a string to an enum. I created a typedefinition for the enum.

When using the Scan From String vi, this works as expected until the output wire goes through the frame of a case.

Please see the image below:

By placing it in a case frame, the type changes to double.

I can connect a constant of the enum type to the default input of Scan From String to force it to be the enum type.

Are there any problems with this? Why does it change to double?

[GerdW]

Hi Max,

the compiler doesn't "see" the enum outside of the case structure and so sets the output of ScanFromString and the output tunnel to DBL default.

To have the output of SFS fixed you should set the type of that output using it's default input…

[max_]

I tried wiring backwards (to make it "see" what type I want), but as I learned not just in this situation, LabView doesn't really like to propagate types "upstream".

It's quite annoying.

[GerdW]

Hi Max,

LabVIEW in general follows the DATAFLOW: you have a data source and a data sink. The source determines the datatype…

What's annoying with this?

(There might be some ocurances not following that basic rule. The ScanFromString might be one of these, atleast when wired directly to an indicator.)

[Sam_Sharp]

Just create a constant of the type defintion for your enum and wire it into the default value of the scan from string.

[max_]

It's annoying because it works without the case frame but not with it.

Contrary to what you posted, it can very well be the sink that determines the data type and not the source. As seen in the first example (without case).

With a case frame, that just becomes a two step process.

I do not see how this shouldn't work the same way.

Here's another example how this makes coding a bit more cumbersome:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Adaptive-quot-Bundle-by-name-quot-from-the-cluster-out...

[GerdW]

Hi Max,

Contrary to what you posted…

I clearly mentioned your case of SFS directly connected to an indicator as "out-of-rule" occasion…

With a case frame, that just becomes a two step process.

Yes. Because the case structure has to make sure it outputs the very same datatype for each case on that output tunnel. And your SFS node outputs a DBL value by default (as you didn't wire the default input!) the case structure will create a tunnel for DBL values!

Simple solution: wire the default input for your SFS node!