There are now custom VI Analyzer tests available for Actor Framework. All are available for LabVIEW 2015 or later.
Open Actor Core Front Panel Set to True checks all calls to Launch Actor, Launch Remote Actor, or Launch Nested Actor, and returns a failure if the input "Open Actor Core front panel? (F)" can ever be TRUE. A value of TRUE at this input will cause errors on RT targets and in executables.
Launch Actor Called in Pre Launch Init returns a failure if an override of Pre Launch Init calls Launch Actor, Launch Remote Actor, or Launch Nested Actor. Such calls will hang your actor system.
Here is the full List of Community VI Analyzer Tests
Thats a cool idea! I was just talking with a customer that he could include some VI Analyzer tests to force his developers not to use global variables in actors
I have this sarcastic inner voice that says "You mean you don't use globals with you actors? Then how do you share information?"
Phoenix, LLC
CLA, LabVIEW Champion
Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!
Ranks right up there with the question, "If I'm not supposed to use local variables, how do I pass data between the frames of my sequence structures?"
You know, it says not to do these things in the documentation, but customers trip over them anyway.
Someday we'll build a hygenic language where such things are impossible. A graphical Haskell is possible (it's what I was working on when I discovered LabVIEW and how I got pulled into NI). A graphical Haskell would address these issues.
Dreams on the far horizon...
Maybe, would be handy to have test, which checks that Actore Core.vi has non-default documentation. I guess, that normal test for VI properties would pass. But if test would check, that module has real documentation, and not default one - then it would force to document actors properly.
How about a VI Analyzer test for branched actor class wires?
From an old forum post regarding nested actors:
The takeaway is "never copy the actor object". Problems with Launch Nested Actor are only one of the issues you'll run into. Don't fork the actor object to your own loops ... harvest what values you need from it, like its Self Enqueuer, and then pass it along to the Call Parent Node. Don't keep a copy for yourself for any reason.