LabVIEW Idea Exchange

This is written as both an Idea and as a Community Nugget.

Did you know there exists a function that decreases code fragility when it comes to typecasting and type converting datatypes? It's called 'Coerce to Type', and I bet you've never heard of this function unless you have kept up with this conversation. Thanks to RandyP for creating that Idea which culminated in a 'public' release of the Coerce to Type function.

Since that post, I have become aware of potential risks/bugs I had been proliferating in my coding style. First, I will briefly describe my understanding of the difference between typecasting and typeconverting in the context of LabVIEW. Next, I'll show a few use cases where this node increases code robustness. Finally, it's up to you to Kudos this Idea so we get Coerce to Type officially supported and in the palette!

Simply, "type converting" preserves the value of a wire, and "typecasting" preserves the raw bits that express that value on a wire. These two concepts are not interchangeable - they perform distinctly different data transfer functions (which is why they show up on two separate subpalettes: "Numeric>>Conversion" and "Numeric>>Data Manipulation"). Then there's this new function: Coerce to Type. I think of it as a Coerce-Cast combo. The data input is first Coerced to the datatype harvested from the top input, and then it is typecasted to that type.

Dynamic event registration is sensitive to the name on the wire, and for documentation's sake it has historically been important to typecast the event source ref to achieve a good name. Well, typecasting refs can get you into trouble (ask Ben), especially if you change the source control type while forgetting to update your "pretty name" ref constant.

My next favorite example is when you need to coerce a numeric datatype into an enum. Sometimes it's impossible to control the source datatype of an integer, while it's desirable to typecast the value into an enum for self-documented syntax inside your app. 

For instance, take the "standard" integer datatype in LabVIEW - I32 - and cast it to an enum. You're going to get some unexpected results (assuming, you expected the *value* to be preserved). Consider the following scenario:

1. You desire to typecast a plain integer '2' into an enum {Zero, One, Two, Three}, and after 45 minutes of debugging, realize "Typecasting" has hacked off 75% of the bits and clobbered the value. Drats!
2. The enterprising engineer you are, you determine how to fix the problem with a deftly-placed "Coerce to U8". (This is one of the fragile errors I proliferated prior to learning about this node)
3. Maniacal manager/customer comes along and says "I want that enum to count to 10k". Drats again. A datatype change from U8 to U16 for the typedef'd enum, and a lot of typing with the wretched enum editor. Finally, two hours into testing and wondering why the program doesn't work, you realize you also forgot to replace all of the Type Converts to U16 (this is the definition of fragile code: you change one thing, and another thing(s) breaks).
4. Rockstar Programmer Epiphany: use Coerce to Type, bask in your robust code. You even enjoy data value preservation from floating point numbers.

With text based languages, the For Loop has a programmable starting index, stopping index, and step size.  With Labview, the starting index is always zero and the step size is always 1.  It is not changeable.  I would like to see Labview have a real For Loop where there would be three terminals inside the For Loop that can be set by the user.  One terminal for initial value (starting index), one for final value (stopping index), and one for step size.  This would be of great value to all Labview programmers.  Of course the terminals can be much smaller than what is displayed in the picture.  One or two letter terminals, such as ST for start, SP for stop, and SZ for step size would do fine.  (or N for initial value, F for fnal value, and S for step size).  The real for loop should be capable of going in a negative direction, like starting at 10, ending at -10, with a step size of -2.

Issue:

Dynamic Launching of a VI works fine when the plug-in code is launched from the LabVIEW source code.

When the Application was build it fails to launch the VI. Upon debugging I found that I am reusing some of the SubVIs in the plug-in VIs that is part of the EXE. I tried renaming and re-linking of those Vis for the Plug-in VIs it works fine.

Solution:

           Similar to Name spacing provided by Lvlib files. Add an additional option in the Exe build spec, to add a name space for the application this will rename all the VIs as "my project:main.vi, My project:test1.VI" etc inside the Exe. This will resolve the naming issue created by the LabVIEW runtime engine. So a plug-in VI can reuse the test1.Vi from the Source code.