Intaris--I'm frankly amazed that you're able to use malleable VIs in a version of LV that is 2 years older than the version in which they were released. Did you have to do anything special to allow that code to compile or make the IDE not lose its mind? (Fingers crossed, I will not be trying this myself, but you've piqued my interest!)
Trying not to get hung up on semantics, but a significant design flaw = an edit-time bug in the IDE
Inlining a VI abstracts placement and compile details from a human reading the code. A VIM is an inlined VI with the special ability to allow polymorphism to traverse its connector pane. In no other instance does a developer need to delete and replace an inlined subVI to trigger the environment to update a VI's functionality (inlined or otherwise). Unless I hear an explanation directly from Aristos Queue (or someone at NI with similar qualifications) that this is either a known limitation in the IDE's ability to handle malleability or intended--for a reason I have yet to comprehend--it is an issue to be solved by NI, and hopefully soon.
It's how I understand it, yes. But like I said, I'm working in an older LV version, things may have changed.
But you shouldn't think of a vim as a sub-VI. It isn't. It's more like the option "drop the contents of this VI when dragged". But with a get-out-of-jail free option to update later.
This is not true. If you right click and select convert instance VI to standard VI you lose the connection to the malleable VI, but otherwise any changes made to a malleable VI propagate to all instances.
But you shouldn't think of a vim as a sub-VI. It isn't. It's more like the option "drop the contents of this VI when dragged".
That would be madness! How would you ever keep track of what code is running where? How would you update all your malleable VIs in your project when you update the .vim source? Thankfully, this is not the behavior that I'm familiar with in later LabVIEW versions.
I'm using LabVIEW 2017 SP1 and LabVIEW 2018 and make extensive use of malleable VIs.
I have seen issues when trying to relink libraries that contain malleable VIs where the VIs containing .vims aren't properly marked as 'dirty' by LabVIEW and are not able to be recompiled properly (they show up in dependencies with a yellow triangle). To get around this, I added a few methods to the open source @cs/ci package on GPM called 'relink' and 'recompile'. Relink solves the problem using GPM-specific files, and Recompile works on any LabVIEW project. The recompile function works by getting all the project items and their dependencies, sorting them by dependency, forcing a compile, and then saving everything.
This was the function that finally solved the 'missing dependencies' issue when relinking libraries that contained malleable VIs. It feels like this could be improved under-the-hood in LabVIEW; maybe it has been in a newer version?
Hey Steve! Thanks for jumping in. I will look up those two tools and give them a try when I get some free time. Those sound like they could resolve the issue for me.