Actor Framework Discussions
How to flush AF queue?
It sounds like a significant fraction of your problem might be possible to solve using the Message Priority field available when sending a message.
If you queue the test steps at a low or normal priority, you could send a high priority message to block steps.
To then skip through remaining messages, you could either change the VI called by the test messages to check some value (boolean or into, perhaps) to determine if it should proceed, or you could provide an implementation of Receive Message (I think that's the name) to drop messages of the specific type based on a similar boolean or int flag.
@Ironman_ wrote:
Nope, you can't drop messages like you say.
A message class can override "drop message core":
"Defines what a message does if it is in the message queue when the queue is released. At this point, the actor has shut down, so it will never process the message."
It's not my case.
As for message priority, documentation doesn't say anything about priority politic :///
Respectfully, you're wrong. You can drop messages like I say. Attached are a small example project I wrote for you showing dropping by the two criteria I mentioned (although if you wanted to use this, you should take more care regarding the error code value, connecting error wires, and probably remove the front panel updates in the calling actor because the UI switch is slow and likely unnecessary except for demo purposes).
It's saved for 2017 and 2014, and I wrote it in 2017. I haven't tested the 2014 version. If you need an older version, let me know.
As you mention, "Drop Message Core.vi" is for handling messages remaining in the queue when the Actor stops - "Receive Message.vi" (as I said) is the one called when messages are about to be processed.
All of that being said, as Colin pointed out, if your messages take a long time to run then you should consider passing them off to a separate queue for handling, so that your messages to that actor can always be handled in a timely manner. In the example project I attach, the actor will still take the remaining wait time for the current message before changing behaviour or exiting when Stop is clicked. Depending on how quickly you need to interrupt your tasks, you might need to additionally allow communication with an executing VI to stop the execution mid-step.
I can't use the solution with "receive message" override, because it's too dangerous and doesn't scale.
1) It doesn't scale bc of "preserve runtime class". Your example works but it's too simple, and I don't want to add more msg classes to the "test if it's a class"....
The receice msg triggers for *every* msg, and it's VERY dangerous, I got locked out for the first time (you know: actor stop, but libs are locked means something is still running), and I don't like it.
2) I used "send batch msg", passing the msg array ["run test 1 msg", "run test 2 msg", "run test 3 msg"], and I noticed that this doesn't correspond to 3 messages! but it is indeed a SINGLE message, that will call 3 methods on the actor.
So this is much different than send 3 separates msgs, and bypasses the "receive msg" overload shenaningans.
Now I will try the solution with the "embedded queue"
PS: I also noticed how dangerous is to (mis)click "run continuosly" on the laucher.vi 
Some interesting points indeed.
Regarding scalability, you could consider having your test messages inherit from some specific message class and test against that - I haven't checked but it should be you can just make the change via the inheritance page in class properties after using the Message maker like usual.
Regarding batch messages - I hadn't considered that. Probably if you use batch messages (sounds like you do) you'd need to include that as a type to check against, possibly separately, then do the work of unpacking the batch message yourself. I agree this is messy (and I don't remember from the top of my head exactly how it is unpacked - presumably in Batch Msg:Do.vi).
An alternative would be to provide a message to a "My Batched Action.vi" which called the three parts together. This is effectively the same as a batch message, but if you frequently create different collections of messages it isn't really feasible...
Regarding the launcher - yes, probably not a good choice for run continuously. Normally I'd remove those options and/or add a dialog to the launcher, but for forum demo code... Sorry you had a bad experience with it.
