LabVIEW Idea Exchange

Allow type casting between Strictly Typed VI References

Why:

The asynchronous methods require strictly typed VIs. Strictly typed VIs depend on the connector pane and terminal wiring type (Required, Recommended, Optional). Depending on your development environment and configuration options (Front Panel > Connector pane terminals default to required), newly connected terminals may be Required -or- Recommended. 

Opening a VI reference or calling an async method with the wrong terminal wiring type will result in Error 1057: Type mismatch. 

To work around the connector pane variance, we need to type cast check every connector pane terminal variance in order to call the proper async method without getting the Type Mismatch error.

The amount of unnecessary complexity to call and collect a thread is infuriating. There is already enough complexity when it comes to spawning a new threads; between the conditional options (Non-Reentrant, Reentrant, Async Forget, Async Collect), VI type specifier (Generic, Strict), Connector Pane Type (Pattern, Rotation), Terminal Wiring Types (Required, Recommended, Optional), etc. Threading in LabVIEW needs improvement.

Idea:

To better support Asynchronous calls, we need the ability type cast the required strictly typed VIs to:

1. Add an option to Start Asynchronous Call and Wait on Asynchronous Call methods to ignore the VI terminal wiring type flags:

     Required (0x21000), Recommended (0x20800), Optional (0x20000)

2. Support type casting VIs To More Generic Type and To More Specific Type to avoid the error 1057 Type Mismatch all together

Regards,

A LabVIEW Enthusiast 

My 2 cents: would be nice to have optional tabs on the case structure similar to what we have in modern browsers like chrome. If dont have gazillion cases then this would be a very comfortable way to switch between cases. Arrows at the side shift the cases. The active case is color coded and slightly overlapping the surrounding cases.

Warning: MS paint artwork below! 🙂

I'd like to see added to LabVIEW  a 'Retain String Formatting' option for the concatenation operator. This would cause string formatting (the stuff you set with the CTRL-0 shortcut) to be preserved when concatenated. See the example below. This could be added to the right-click properties of the concatenation operator "Preserve String Formatting". An alternate symbol for concatentation would need to be provided so that you could visually tell that this option was enabled when looking at the concatenation operator on the block diagram. Maybe the NBC peacock sitting on top of it?

Sometimes setting string formatting attributes programmatically is a lot of work, and inappropriate to the application; simply not changing/removing the attributes would be sufficient... Note that the string formatting attributes are preserved across a cut-and-paste - if you copy the contents of a formatted string and paste it into another string, the attributes are retained. I find the current behavior of the concatenation operator  (NOT retaining string attributes) to be at odds and inconsistent with LabVIEW. After all, it is a GRAPHICAL programming environment, is it not?

If I remember correctly, you also lose string formatting attributes when changing a string constant to a control or indicator - perhaps that also could use some thought...

Hi Team,

Would be Great to add or Delete Input in Array [ Insert Into Array ]. Bit difficult to manage when used for reporting. Rearrange all input nodes if to add or delete a input inbetween.

Many Thanks

Anbu