the_mitten

Interesting! Didn't realize that. Thank you!

Huh. Yeah, I didn't expect this. Doesn't this suppose that the user hasn't changed the displayed label text for the subVI?

Has anyone found any properties or methods associated with malleable VIs? Specifically, I was hoping to find a way to invoke the "Convert Instance VI to Standard VI" function after confirming that a selected VI was indeed malleable. LabVIEW reports the class type of a selected malleable VI on the block diagram as a standard Sub VI, and I didn't see any properties/methods under the VI class. I'm exploring what it would look like to make a utility to convert a malleable VI into a polymorphic VI for the purpose of backwards compatibility. I'd like to have a reference library that uses malleable VIs but create a version that is still accessible to someone using older versions of LabVIEW that don't officially support malleables.

CAR 671221 was fixed in LabVIEW 2017 SP1. The best place to look is in the bug fixes list for the appropriate LabVIEW version (here is 2017 and 2018) or in the patch details (2017 and 2018). As you'll notice, this specific CAR number is not called out on any of these pages. Not every CAR that is fixed is published online, but you can always contact the support team to determine if a specific CAR was fixed.

That's a good point that I hadn't considered. In my mind the usefulness of the Write VI is more of the case of quickly initializing or otherwise performing a reset/overwrite of the existing value of the DVR, and to be used in conjunction with the IPE structure and the read/modify/write paradigm as normal. An example for me recently is needing to ensure that a DVR used throughout the application was initialized to defaults after a certain sequence had executed. Hence, wiring a constant to this VI was much more convenient. Does that seem more reasonable, or still prone to error rather than helpful? I definitely see how this could be misused such that the critical code is placed outside of the IPE. I'll work on coming up with a better example to show more of the specific use case and provide a clearer explanation of when it could be helpful.

The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert. Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE. This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it. A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value. Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. I’ve created two malleable VIs, Read DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type. Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values. Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments! DVR Read and Write VIs 1.0.0.zip