Understanding Stop User Event in Actor Framework

[govindsankar]

I have seen some videos online, where in Actor Framework, the actor is stopped by generating a user event. So for that we create a user event in pre init by taking a boolean variable, naming it false and connecting it to create user event and then creating a control from its output and storing that in the private data of the actor. Then in actor core, unbundle the actor, use register for user events and connect it to dynamic user event terminal in the event structure, select the user event and then send true to the while loop around the event structure to stop it. And finally destroy the user event in the stop core.vi. But what I dont understand is how do we generate this user event. What the program does is use panel close to stop the actor and the progam. But then what is the purpose of the stop user event. How does it work. Thank you. 

[Jay14159265]

---

@govindsankar wrote:

I have seen some videos online, where in Actor Framework, the actor is stopped by generating a user event. So for that we create a user event in pre init by taking a boolean variable, naming it false and connecting it to create user event and then creating a control from its output and storing that in the private data of the actor. Then in actor core, unbundle the actor, use register for user events and connect it to dynamic user event terminal in the event structure, select the user event and then send true to the while loop around the event structure to stop it. And finally destroy the user event in the stop core.vi. But what I dont understand is how do we generate this user event. What the program does is use panel close to stop the actor and the progam. But then what is the purpose of the stop user event. How does it work. Thank you. 

---

Hello, I know that I have given you some advice in the past in which I said you "cant" do soemthing and then someone else came in and showed you how to hack your way around a limitation of the actor framework. I realized that I should not have used the word "cant" and instead should have said "it's best not to". Well now that you are down the rabbit hole of using user events and listeners in actors (which I consider a hack because NI did not expose the ability to have a native "user event" override in the actor base class, but they should have! you now have to hack your way around this shortcoming in the AF). 

Instead of offering a solution I can only offer some opinion. I think the engineers at NI did not necessarily intend for actors to be used for front panels, they were designed for highly parallel asynchronous operations that are extensible and they work very nicely for that purpose. Then at some point they needed to make a demo of how the AF worked but there is no native Actor support for front panels so they hacked together that demo that used user events and listeners and the actor framework has been confusing people ever since : /

Maybe I'm wrong here too, I enjoy using the actor framework and wish it had extensible support for interacting with the front panel but I have never found it. Using the user events and listeners seems like a hack to me as it's not clean and it's not extensible it's a band aid. As you describe in the scenario you propose, that sounds like a huge hack to be able to stop an actor core, why does it need to be that hard. 

[cordm]

You have the helper loop that is stopped by the user event.
You also have the message handling loop that is stopped by the Stop Message. 

Both loops must stop for the actor to shut down.

The shutdown command does not need to come from the UI.

The message handling loop could stop due to an error. If you do not generate the user event, the UI would continue running and most likely behave weirdly.

It may not be relevant in your case, but a UI actor does not need to be the root actor, it could be nested. The calling actor would signal a shutdown by sending a stop message to the nested actor. That is where the generate user event is required.

You could also stop the helper loop with any other method, like checking a stop variable. I find it convenient to use a user event for this because I can use it for multiple loops and pass it to a sub VI.

[PsyenceFact · Accepted solution]

If you want to use the user event to stop the helper loop in your override of Actor Core, create the event as you have done then trigger the event in your override of Stop Core.  When your actor receives a Normal Stop, the Call Parent Class Method in your Actor Core ends and Stop Core runs.  By triggering the event here, your helper loop can also be stopped and Actor Core will finish running.

PsyenceFact

[govindsankar]

Oh yes, I am an idiot. Of course when you stop an actor, the stop core gets called and thats where you generate the event. I already did that in my program because it is the same thing that is done in the video, but I was thinking we have to generate the event in the actor core itself. Now I get it, so when you stop the actor, the stop core gets called where user event gets triggered and then the even structure in the helper loop while execute this user event and then stop the helper loop. Thats how it works. Got it. Thank you. 

[PsyenceFact]

Glad you've got your head round it!  I've been using the Actor Framework for about 8 years and I still keep getting tripped up by little details like this.

PsyenceFact

[BertMcMahan]

Yeah I've made a crapload of front panels with the Actor Framework and it works great. I highly recommend the MGI Panel Manager toolkit which can help with some of the smaller stuff, including having some template code that means you don't have to manually add the "stop front panel" user event stuff.

And yeah, like others have said the Stop user event is to stop the front panel of the Actor, not to stop the Actor itself. Not sure why that would be considered a hack. I guess NI could've included that in the base Actor class, but it's such a non-issue with that toolkit that it's really no big deal. I would admit it'd be nice if NI bundled that stuff into AF Core, but I only have to install it once so eh 🙂

[Jay14159265]

---

@BertMcMahan wrote:

...

Not sure why that would be considered a hack. I guess NI could've included that in the base Actor class, but it's such a non-issue with that toolkit that it's really no big deal. I would admit it'd be nice if NI bundled that stuff into AF Core, but I only have to install it once so eh 🙂

---

I am no expert on the Actor Framework but I have been using it for around 6 years now. One of my main clients has a "no external libraries" code policy that prevents me from using any of the MGI toolkits (or any others for that matter) for those projects, and those projects are 90% of the code I do in LabVIEW. 

This scenario is good and bad, it's good because I have to roll my own libraries for everything and it's bad because I have to roll my own libraries for everything. For the actor framework my opinion is that the way it is currently implemented in stock LabVIEW it is unfinished. The reasoning for this is that by definition the only way that you should interact with an actor is via an actor message, not a listener or a reference. Not to say a listener is bad or wrong, it simply breaks the paradigm on which the actors are supposed to work. Now if NI had exposed a way generate an actor message from a UI front panel user event loop, and had a user event override of the base class actor, I would consider that fully implemented for use with UI front panels. But as it stands now, in my opinion, the user event and listeners paradigm in the Actor Framework is a bit of a hack. Either way, I enjoy using the Actor Framework and hope that NI will continue to improve it. 

[BertMcMahan]

---

@Jay14159265 wrote:

---

The reasoning for this is that by definition the only way that you should interact with an actor is via an actor message, not a listener or a reference.

---

I always assumed this was in relation to talking between Actors, not inside of one. Helper loops inside an Actor need ways to communicate "normally", and I've always considered my UI Event Handler to be a helper loop the same way I'd have a DAQ servicing loop or a serial port monitoring loop. IMHO it's not breaking the paradigm as long as I'm not sharing those resources to other Actors.

I will admit though, it's a pain to have to create a message to send to yourself from the Event loop, and it would be nice if an Event could act as a Method like you're saying... but then again, I have found myself reusing messages "I'll only ever need to send to myself" from other Actors before, so it's not all bad.