Same Abstract Message for Caller from Two Different Nested Actors

[ihyd-zmay]

Forgive me is this is a silly question, I'm rather new to using the Actor Framework.

I have a calling actor that launches two different nested actors. These two actors are similar, but their behavior is extremely different. I want these actors to both send a message back to the caller with some data letting the actor know that their task completed, any issues that occurred, etc. and I have the messages formatted such that both actors send the same message cluster back to the calling actor. I thought I would be able to setup one abstract message to caller in each nested actor, and one child of abstract message in the calling actor.

So that's what I did. I created an abstract message for nested actor 1 and nested actor 2, then created a child of the abstract message for nested actor 1. Unfortunately, I'm having trouble with the Write VI created by the abstract message scripting for the abstract message in nested actor 2. I get the following message when trying to connect the message class for the parent to the Write VI of the nested actor I did NOT use to create the parent message (I hope that makes sense): "You have connected a refnum of one type to a refnum of another type and both types are members of some class hierarchy, but there is neither a simple up cast nor type cast between the two classes".

Do I have to make another VI that's a child of the abstract message generated for nested actor 2? Or is there a way I can coerce the message object generated for the calling actor to work for both nested actors Write VIs?

[OneOfTheDans]

Typically your messages should belong to the receiver, not the sender. So in your case, only one status message is needed, and it should belong to the Caller. Then both nested actors will use Send Status.vi to build and send the message to their Caller.

The next level up is to use an interface instead of the message depending directly to the caller. To do this:

1. make an interface (like Status Receiver.lvclass)
2. give it a method (like Status Receiver.lvclass:New Status.vi)
3. create an AF message against Status Receiver.lvclass:New Status.vi
4. change Caller.lvclass to inherit from Status Receiver.lvclass
5. override the interface's method, to create Caller.lvclass:New Status.vi

Sorry it's a bit wordy description, but once you've done it you'll find this approach is quite straightforward. This "interface style" of messages has basically replaced the more-flexible but more-cumbersome "abstract messages".

[justACS · Accepted solution]

Your AF experience will be substantially better if you have access to interfaces.  If at all possible, you should move your project to LV 2021 SP1 or later.  (You need the service pack, because it fixes a bug in the AF tooling.)

That said, I assume you have a pressing reason why you haven't migrated, so I'll address the question you asked.

The abstracts you created for Actor 1 and Actor 2 are distinct classes.  As you have discovered, you cannot use a child of Abstract 1 where a child of Abstract 2 is expected.

You have two options.

1.  Create a separate method of the calling actor, to be targeted by a child of Abstract 2.  In some ways, this is the most correct, because it preserves the relationship information in the message call - you will know that if you get Message 2, it is from Actor 2, and you can respond differently.  Even if you don't want to do so now, you might in the future.

2.  If you truly expect that the caller will always respond the same way regardless of sender, you can remove Abstract 1 from the actor library.  The decision to link abstract messages to a particular sender was arbitrary, and in hindsight, a bad call on our part.  So pull it out, and (optionally) stick it in a separate library.  Make both Nested 1 and Nested 2 use the same abstract message, and then you can have a single child message to the Caller.  (You still have the option to have separate child messages in the future, if you need them.)  If you're confused, see my talk on this subject, here starting at the 35:15 mark.