"Scan From String" - something I didn't know...

[JÞB]

---

@billko wrote:

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Interesting.  There are undoubtedly other "features" to be discovered ...

Bob Schor

---

Hmmm, if you create an indicator directly from the output, you get "output 1" as the indicator label, but the wire is named "Test Value 1".  But if the wire goes through a tunnel and you create the indicator from that, the label of the indicator takes the name of the wire...

---

OK y'all, old dogs missed a few tricks!(luckily I'm in the south so I can used the gender inclusive "y'all" without offending anyone who doesn't self identify with the group Guys) 

The label magic comes from the label of the wire segment.  Try it! Label a wire segment to the scan from inputs then create a constant!  The direct output wire will default to the default input wire label. HINT: go to tools>> Options and select Show Labels on Constants.  A branch plays funny ( that segment could have its own label.)

Tim's example is a bit misleading.   The format string is string string numeric numeric separated by commas.  As long as the default scan inputs match the format string we can reorder the outputs.   They are interpreted top down in format string order so the first TRUE is picked up by the first Enum that has a TRUE as one of its value strings  The second TRUE could conceivably be picked up by either an Enum containing a TRUE value string or a boolean.   Similarly,  a "1" could be either the string of an Enum containing a value of 1 or, a boolean "T."

Thanks Tim, for reading the help file so closely that you could come up with that super obfuscated example.

[paul_cardinale]

---

@JÞB wrote:

---

@billko wrote:

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Interesting.  There are undoubtedly other "features" to be discovered ...

Bob Schor

---

Hmmm, if you create an indicator directly from the output, you get "output 1" as the indicator label, but the wire is named "Test Value 1".  But if the wire goes through a tunnel and you create the indicator from that, the label of the indicator takes the name of the wire...

---

OK y'all, old dogs missed a few tricks!(luckily I'm in the south so I can used the gender inclusive "y'all" without offending anyone who doesn't self identify with the group Guys) 

---

Whereas I am old and crotchety, and anyone who doesn’t like my word usage can go pound sand.

[billko]

---

@JÞB wrote:

---

@billko wrote:

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Interesting.  There are undoubtedly other "features" to be discovered ...

Bob Schor

---

Hmmm, if you create an indicator directly from the output, you get "output 1" as the indicator label, but the wire is named "Test Value 1".  But if the wire goes through a tunnel and you create the indicator from that, the label of the indicator takes the name of the wire...

---

OK y'all, old dogs missed a few tricks!(luckily I'm in the south so I can used the gender inclusive "y'all" without offending anyone who doesn't self identify with the group Guys) 

The label magic comes from the label of the wire segment.  Try it! Label a wire segment to the scan from inputs then create a constant!  The direct output wire will default to the default input wire label. HINT: go to tools>> Options and select Show Labels on Constants.  A branch plays funny ( that segment could have its own label.)

Tim's example is a bit misleading.   The format string is string string numeric numeric separated by commas.  As long as the default scan inputs match the format string we can reorder the outputs.   They are interpreted top down in format string order so the first TRUE is picked up by the first Enum that has a TRUE as one of its value strings  The second TRUE could conceivably be picked up by either an Enum containing a TRUE value string or a boolean.   Similarly,  a "1" could be either the string of an Enum containing a value of 1 or, a boolean "T."

Thanks Tim, for reading the help file so closely that you could come up with that super obfuscated example.

---

I've used this wire label trick when creating subVIs from code.  I didn't realize there was a connection here.

[crossrulz]

---

@JÞB wrote:

Thanks Tim, for reading the help file so closely that you could come up with that super obfuscated example.

---

Wait...There's a help file on this?  Honestly, I just tried them one day and they worked!  However, I do have a printout of the "Format Specifier Syntax" and the "Format Codes for the Time Format String" help files.  My current copies are from 2016.

[wiebe@CARYA]

Remember to carefully think about putting %.; or %,; in that format string, whenever dealing with floats

If you don't, you're software will fail for about 50% of the computers.

A ',' as decimal separator is pretty common over here. I suppose most programmers simply ignore this.

Of course there's the global setting to ignore this globally, but I value the user's configuration. So, everything on the UI (or what the user is going to see, like PDF reports) should use the regional settings (no "%.;"), and everything 'hidden' (like log and config files) should use "%.;".

[Yamaeda]

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Bob Schor

---

I guess it's connected to the thread somehow, but naming constants is quite important if bundling without names, as you can't access all data with a Unbundle with name without it. The unnamed unbundle works as it shows all outputs. I guess you can use this to 'hide' some data in some obscure situation. 🙂

[wiebe@CARYA]

---

@Yamaeda wrote:

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Bob Schor

---

I guess it's connected to the thread somehow, but naming constants is quite important if bundling without names, as you can't access all data with a Unbundle with name without it. The unnamed unbundle works as it shows all outputs. I guess you can use this to 'hide' some data in some obscure situation. 🙂

---

This is also important when working with variants, as they get a label based on the wire's name.

I have tooling where a variant gets stored (and set) automatically. I can simply wire a double with a label Section_Key, and the value gets stored in Section, with the Key. As it accepts variants, this also automatically stores values coming from a value change event, as those variants also get the label of the control that triggers the event.

[billko]

---

wiebe@CARYA wrote:

---

@Yamaeda wrote:

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Bob Schor

---

I guess it's connected to the thread somehow, but naming constants is quite important if bundling without names, as you can't access all data with a Unbundle with name without it. The unnamed unbundle works as it shows all outputs. I guess you can use this to 'hide' some data in some obscure situation. 🙂

---

This is also important when working with variants, as they get a label based on the wire's name.

I have tooling where a variant gets stored (and set) automatically. I can simply wire a double with a label Section_Key, and the value gets stored in Section, with the Key. As it accepts variants, this also automatically stores values coming from a value change event, as those variants also get the label of the control that triggers the event.

---

This is not so with NXG, which is probably the biggest reason I abandoned it.

[wiebe@CARYA]

---

@billko wrote:

---

wiebe@CARYA wrote:

---

@Yamaeda wrote:

---

@Bob_Schor wrote:

I'm like Crossrulz -- I knew about wiring Inputs to get specific types of Outputs, but didn't know about naming the constants (though I've used Named Constants in other situations where I've needed to "name a constant" -- I don't remember the exact use now, after the Stupor Bowl).  However, Bill's example is peculiar -- in order to get the Indicator wired to the output of Scan from String to take on the "name" of the Input Constant, you need to bring the output wire into a Frame Sequence (or maybe any other structure).  Crossrulz' example illustrates this -- notice an input constant named "Enum String", while the output is named "Enum Strnig".

Here's Bill's example using a Case Structure instead of a Frame, and showing both types out Created Indicators:

Bob Schor

---

I guess it's connected to the thread somehow, but naming constants is quite important if bundling without names, as you can't access all data with a Unbundle with name without it. The unnamed unbundle works as it shows all outputs. I guess you can use this to 'hide' some data in some obscure situation. 🙂

---

This is also important when working with variants, as they get a label based on the wire's name.

I have tooling where a variant gets stored (and set) automatically. I can simply wire a double with a label Section_Key, and the value gets stored in Section, with the Key. As it accepts variants, this also automatically stores values coming from a value change event, as those variants also get the label of the control that triggers the event.

---

This is not so with NXG, which is probably the biggest reason I abandoned it.

---

That was a big downer...

[DavidBoyd]

This! What Wiebe said about proper usage of the regionalization overrides on floats.  I was bitten by this (exactly once, and definitely never again due to ignorance).  My mistake involved parsing the text of configuration files supplied with an application that uploaded data into a device.  Field service depots overseas started reporting the update process caused the devices to misbehave.  The configuration files were of course using decimal radix, but their localization was set for commas.

I hadn't even considered the possibility (in truth I generally wasn't making applications with an audience past our local manufacturing floor), and our software V&V team of course hadn't tested against non-US Windows localization settings.

The other comment I really wanted to make:  as a long-ago C programmer, I've always used LV's Scan From String and Format Into String nodes for their versatility and coherence with C stdlib's sscanf() and printf() and their ilk.  That entire subpalette of Number/String Conversion one-off nodes is a no-go zone for me (20+ years of LV programming). Give me error terminals, offset past match, and growable inputs/outputs!

Dave