LabVIEW
Bug: Delete element using CTRL+Delete only visually updates data
Solved!
I kudos your post (friendly reminder to whoever is reading).
This is a can of worms. Someone made a bobo...
Search LabVIEW like a graph! 
@FixedWire wrote:
Not sure if this issue is related but I found the output of a string indicator was simply not providing the correct values when called as a subvi. This bug looks eerily similar.
This code was working a long time during development when suddenly the results were incorrect. The only way to get rid of the issue was to delete the indicator & recreate it. This is a !@#$ of a problem as it could go undetected. This simply can't happen in a regulated environment.
We definitely see something similar happen in one of our projects. It’s a large project based on many plugins in the form of classes inside packed libraries, And it is running on cRIOs which we found to be extra tricky when it comes to using PPLs.
The basic of the plugin works in a way where the Constructor of the class gets a JSON formatted string and also passes this to its parent and so on. What we see first is that it won’t usually run at all if a higher level plugin is rebuild without also rebuilding every single inheriting child plugin, even if nothing in the interface changed at all. On Windows this behavior doesn’t seem to happen but on the cRIO it looks like a plugin somehow remembers a private.hash or timestamp on PPLs it depends on and refuses to load unbroken if that doesn’t much anymore.
But every so often we also see the situation that the JSON string appears correct in the top level caller but suddenly disappears in the lower levels and only gets passed as empty string through. Sometimes rebuilding the entire code bases fixes this but not always. Cleaning the code cache seems also sometimes to be helpful. Restarting LabVIEW alone seems to do nothing, but restarting and rebuilding all a few times eventually magically fixes it. This is with LabVIEW 2019 SP1 f1 on Windows 10 for 9035 and 9045 cRIOs. It’s still not clear to us what exactly triggers this and what eventually fixes it for a while.
I've had child VIs of reentrant class hierarchies simply stop working.
So with a simple composite pattern (one child has an array of the parent), there used to be states where the child implementation of a method where not called anymore. If the composite is recursive, the VIs need to be reentrant.
This is dangerous, at it sometimes stays unnoticed. It's also hard to debug, as the very basis doesn't work as expected.
My solution used to be to change the connector pane of each method, as even restarting LabVIEW didn't fix the problem. I didn't use separate compiled code back then. This was not just once. In some projects it happens so often, I made a scripting VI to disconnect\connect a control from each method of the parent.
I haven't seen this in LV20 (yet).
