LabVIEW
BUG: VI unloads from subpanel when InsertedVI property is called from an asynchronous process
@drjdpowell wrote:
I vaguely recalled trouble with InsertedVI and looked up the code and found this reference: https://forums.ni.com/t5/Actor-Framework-Discussions/MGI-Panel-Actor-potential-crash/m-p/4344991#M77...
That was my thread, and I actually got a solution to it from NI tech support! He was able to get it forwarded up to LV R&D, who gave the compliment of "this is an interesting bug." It is fixed in LV2024 Q3, but as the OP isn't getting access violations (I don't think) then it's probably not the same thing.
But, he could test it out by adding "CodeRegistryMaxCacheEntries = 64" to his built executable's .ini file and seeing if that fixes it.
My issue wasn't anything to do with the Panel Manager, it was to do with reusing clones of VI's that had maps in them- or having a Map of classes that may be cloned- or something. I didn't get the full, in the weeds explanation (nor would I understand it anyway) but adding that to the ini file fixed it, and apparently it's fixed in the latest LabVIEW (though I did hear there was another similar-ish bug that's fixed by this ini file change with a fix ETA of Q3 2025.)
InsertedVI is evil.
Simply don't use it or prepare for maximum weirdness...
I don't know why this hasn't been fixed, it has been evil right from the start. It's probably too much of a niche problem, or maybe it hasn't attracted the attention of the right person yet despite mentioning it over and over again.
InsertedVI seems to return some sort of internal reference, not a new reference. Not closing the reference is problematic, but closing this reference is even worse. Closing it seems to keep the VI in the panel even when the main VI isn't running, yet the VI in the panel isn't running. It's definitely a huge bug and exploring it's limits will certainly hang or crash the IDE...
Don't use InsertedVI is the only workaround...
The other way around (get a subpanel reference of the VI) would be a (difficult) way to make workarounds, but that's so evil we don't even get that luxury (VI property subpanel ref - NI Community).
Search LabVIEW like a graph!
@Yamaeda wrote:
I don't like the idea of a Panel inserting and removing itself, but then i've never touched AF.
In my experience, that's the best (maybe only) way. Regardless of AF.
Esp. with recursive nesting of clones in subpanels, this is the only way to make sure clones ere removed from subpanels before their reference is cleared. When done any other way I found LabVIEW will crash without finding a real cause. Making the inserted VIs in charge is the only way I ever got this working stably when things grow complicated.
Registering dynamic front panel events is also very hard if the inserted VI doesn't have full control of it's front panel. This is another hell that needs to be improved: registering events fails if the panel is closed (although static events work just fine) but inserting in a subpanel fails unless the panel is closed. So the Vi ether needs to hide itself, register events, close itself, and then signal it can be inserted in a subpanel, or get a signal that it's inserted in a subpanel (which isn't when the insertvi method finishes) and than register events. But the VI won't work well when it isn't running in a subpanel.
This is a typical situation where things should be easy, it could be easy, but unless experienced turns your budget from hours to days.
