Actor Framework Discussions
Just a warning: if you use PPLs or the "Replace with" functionality, DO NOT upgrade to 2019 SP1
There's a bug in 2019 SP1 that may or may not have absorbed a month of my life trying to resolve. The "Replace with" functionality doesn't always work correctly and you can end up with projects in weird states where they're pointing to multiple libraries/PPLs.
NI has opened a CAR for the issue and R&D is investigating. In the meantime, the best solution is to downgrade from SP1 to vanilla 2019.
EDIT: I'm told it also affects the latest prerelease version of 2020, so be careful if you start playing around with any 2020 beta versions.
Reading the first post makes it sound like we should just avoid the Replace With... functionality. Is that true, or is it "PPLs or the Replace with" in the title?
Especially if this is only the reverse direction (lvlibp to lvlib) I'd pick newer and shinier - no? Both are new features but probably that wasn't the only fix in SP1 and although it's a nice feature to have, hopefully it isn't generally a required one.
That being said, I did have a somewhat similar issue with Actor Framework as a PPL and replacing with an lvlib (under SP1) a week or so ago.
Restoring via git didn't initially work, but clearing the compiled cache and then resetting my project again got it back into the desired shape.
Since it was accidental (I dropped an AF.lvlib VI rather than my lvlibp via quick drop) I was fine just moving on.
@Craig_ wrote:
I helped troubleshoot this a little, the replace appears to work (the LVLIB in the project is replaced by the LVLIBP), but there still is a dependency on the original LVLIB. The replace process seems to be not be properly updating the inheritance of child classes to point to the right parent when that parent is moving LVLIB -> LVLIBP.
You can manually fix that inheritance to get the correct state, but if there's a lot of classes this can be a pain!
So I actually DID go through the hassle of manually updating a small project I had to use the correct inheritance. But then the code got into a really frustrating state: when I would finish updating the inheritance, I'd save all, and close the project. Then when I reopened the project, LabVIEW was somehow "holding on" to the original LVLIB reference and had broken all the VIs.
When I reopened the VIs that claimed they were pointing to the LVLIB, the references would then get fixed. But this state would always revert back to broken on a close and reopen, even if I cleared object cache and did a total restart of the IDE.
If I tried to build the PPL in the ostensibly "fixed" state, the resulting PPL would be built with broken VIs and be unusable.
@cbutcher wrote:
Especially if this is only the reverse direction (lvlibp to lvlib) I'd pick newer and shinier - no? Both are new features but probably that wasn't the only fix in SP1 and although it's a nice feature to have, hopefully it isn't generally a required one.
It's both directions. If you've built all your PPLs already and/or never decide to turn an LVLIB into a PPL after integrating it into a project, then may not be something to worry about.
