AF SubPanel Messaging Not Working

[Be-lock-eh]

Hello,

For a project I'm working on I decided to give subpanels a try. I naturally thought the best way to use the subpanel would be to have different "panel" actors my main actor launches and then send a message to each nested actor when it is time to insert itself into the subpanel. When I do this, the overridden actor core of the nested actor indeed shows up in the subpanel but I'm having some problems. I have events set up for my nested actor in a helper loop in the actor core. These events at first seemed to be not responding but I found if I put a one button prompt inside the events, they were indeed firing. The messages though that I'm having the nested actor send itself in each event however for some reason are not being sent to the core. I am using MGI's monitored actor and when I enable logging I can see the messages are not logging (except there was one time I got a message to show but other than that I haven't seen a single message log. The fact I saw one makes me wonder if there is a race condition somewhere but I don't see how there could be.).

When I test the nested actor alone with its own launcher it runs perfectly, but once I insert it into the subpanel it doesn't seem to be able to message itself.

I put a simple error handler right before the "call parent actor core" inside my overridden actor core and there are no errors that could be stopping the core and if there where my user event should fire to let me know.

I don't know what the problem is but this bug is driving me crazy. Any help would be much appreciated.

I've attached my code. The "Scope Station Main" is the main actor that launches the "Config Panel" nested actor. Right after launching the Config Panel actor it sends it a message with the reference to the subpanel telling the config panel to insert itself into the subpanel. This lets the Config Panel initialize before inserting itself into the subpanel.

[alsoACS]

Your code has too many third party dependencies for me to easily load it (I'm not keen on installing all of the MGI packages).  Can you pull out a subset that doesn't have the dependencies, but still shows the problem?

I was (briefly) able to get something running, and I inspected the message traffic using the Desktop Execution Trace Toolkit.  It looks like the message handler in your Config Panel actor core (the Call Parent Node) is no longer dequeueing messages.  That will happen if it hangs on a message or just quits (likely due to error).

Get me a clean copy that shows the problem, and I'll take another look.

[Jacobson-ni]

I also see that messages are being sent to the Configuration actor but nothing is being dequeued.

However, if you send messages from the root actor into the nested Config actor, those will be dequeued and handled properly. You will also see the same behavior if you change all of your actors to inherit directly from Actor.lvclass instead of Monitored Actor so there's no funny business there.

The above shows the Config Panel actor core in case ACS is having trouble opening anything. In this case Config Panel inherits directly from Actor and hitting cancel will send a message which isn't received. Meanwhile the root actor can keep on sending the same message to this actor which gets received. The Init function doesn't touch the actor's enqueuer.

[Be-lock-eh]

Thank you both for looking at my code. This is stumping me pretty hard. I've attached a version with the MGI library removed. I also added a case to the main actor where if you press the "Start Test" button it sends the "insert into subpanel" message to the Config actor and via message logging I can see it is sending successfully. I don't understand how the Config enqueuer could be failing to enqueue. I don't see any errors or anything hanging the core.

[Be-lock-eh · Accepted solution]

Wow I found my problem.

First my error handling of the helper loop was wrong. I needed something to catch the error and stop the helper loop and actor core so I added an or statement to the stop button on the while loop feeding it the event wire and put a case structure after the event structure to send a normal stop if an error is encountered. Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent.

Now to the source of the error:

I have two events in the Config event structure to handle a "Mouse Enter" and a "Mouse Leave" to change the cursor to a pointer finger when the user has their cursor in the table. For some reason this is not playing nicely while in the subpanel. This worked perfectly launching the Config Panel actor alone, but when in the subpanel it throws a null window error on the built in "set cursor.vi" used to set the mouse cursor.

[Jacobson-ni]

@Blahe

Good catch. As always, it seems so obvious after the answer is found.

@ACS

Would you consider it a bug that a message sent trace is generated in the error case where no message is actually sent?

[alsoACS]

---

@Blahe wrote:

Wow I found my problem.

First my error handling of the helper loop was wrong. I needed something to catch the error and stop the helper loop and actor core so I added an or statement to the stop button on the while loop feeding it the event wire and put a case structure after the event structure to send a normal stop if an error is encountered. Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent.

---

Instead of doing that, consider using the Report Error message to pass any error to the message handler, and then deal with the error in Handle Error.  Typically, helper loops shouldn't self-stop.  You can find Send Error Report.vi on the AF palette.  It's a normal message that any actor can receive.  It takes an error cluster as data, and merges that error onto the error wire in the message handling loop.  Handle Error will catch that error and stop the actor (or whatever you specify in an override of Handle Error), which should then stop your helper loop.

[alsoACS]

---

@Jacobson-ni wrote:

@acs

Would you consider it a bug that a message sent trace is generated in the error case where no message is actually sent?

---

The "actor sent message" trace gets sent when Enqueue is invoked.  You should see a corresponding "actor received message"  trace.  If the second trace is absent, then the message wasn't delivered, and you can assume a failure in the message transport.  But the sender *tried* to send the message, which is what the trace means.

So no, I don't think it's a bug.  I might concede that it isn't the most inclusively worded message, but we don't want those trace messages to get too long.  And since there are only a two possible causes for not seeing a receive trace (queue is bad, or queue is seriously backed up/recipient has hung), I'm not really worried about it.

[drjdpowell]

---

@Blahe wrote:

Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent. 

---

Question: why didn’t you see the error via probing the wires?   If I had this problem, my first actions would be:

1) right-click on subpanel and “Open Block Diagram"

2) turn on “Retain Wire Values"

3) exercise the UI a bit

4) hover over the wires in the event loop and look at the values

5) see the error

This seems a much more direct and quick way to debug LabVIEW code than consulting any kind of logging, so I am wondering what prevented you from going this route.

[Be-lock-eh]

---

@alsoACS wrote:

---

@Blahe wrote:

Wow I found my problem.

First my error handling of the helper loop was wrong. I needed something to catch the error and stop the helper loop and actor core so I added an or statement to the stop button on the while loop feeding it the event wire and put a case structure after the event structure to send a normal stop if an error is encountered. Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent.

---

Instead of doing that, consider using the Report Error message to pass any error to the message handler, and then deal with the error in Handle Error.  Typically, helper loops shouldn't self-stop.  You can find Send Error Report.vi on the AF palette.  It's a normal message that any actor can receive.  It takes an error cluster as data, and merges that error onto the error wire in the message handling loop.  Handle Error will catch that error and stop the actor (or whatever you specify in an override of Handle Error), which should then stop your helper loop.

---

Thanks for tipping me off to the "Send Error Report.vi". I went ahead and implemented that and just tested it with a dummy error and it works wonderfully. I'm always open to learning new/better ways of doing things.

[Be-lock-eh]

The problem is you can't highlight execution OR probe a wire in your actor core. It is one of the maddening things about using actor framework. But there are enough advantages I still prefer using it. Sometimes I feel a little blind though not being able to probe the core. I think the only standard debugging thing you can do in the core is put a breakpoint. If I had suspected an error in my helper loop, I probably would already have figured out the solution. I was looking in the wrong place and since my error handling wasn't very good in the core I was unable to see I had a problem there.

So here is what I've changed it to now.

[cbutcher]

You can probe the Actor Core, as Dr Powell described - if you right click on your subpanel (the empty panel) and tick "Allow User to Open Diagram" then when you run the VI and insert the subpanel, you can right click on the panel and choose "Open Block Diagram". This will open the specific clone that is running, which you can then freely probe.

An alternative I sometimes use is to place the following code somewhere near the beginning of my problematic shared-reentrancy VI. If it doesn't pause exactly where you want, you can place the pause before the FP.Open, but I have no idea how that works...

This requires that Scripting VIs be shown, under the Tools > Options menu (VI Server tab). Or at least, it requires that they be shown in order to select the blue node. Probably it still works even if you later hide them again.

[Be-lock-eh]

Oh awesome thanks! I had no idea you could probe the sub panel like that and see the actor core. That's a neat trick. Thanks and sorry Dr Powell I misunderstood what you were suggesting

[AristosQueue (NI)]

There's a far simpler way to open the reentrant clones!

View >> Browse Relationships >> Reentrant Items

For any reentrant VI, that will show you a list of all the existent clones of that VI. You can pick which one to open. It doesn't tell you which is which, but usually there aren't that many, and if there are, you can look at the call chain ring on the block diagram to figure out which is which.

[AristosQueue (NI)]

---

alsoACS wrote:

So no, I don't think it's a bug.  I might concede that it isn't the most inclusively worded message, but we don't want those trace messages to get too long.  And since there are only a two possible causes for not seeing a receive trace (queue is bad, or queue is seriously backed up/recipient has hung), I'm not really worried about it.

---

alsoACS: Did we add a trace message to Drop Message? If not, should we to differentiate the case where the message was never sent from the one where it was sent but not received (because the receiver quit before that message arrived)?

[alsoACS]

---

@AristosQueue (NI) wrote:

---

alsoACS: Did we add a trace message to Drop Message? If not, should we to differentiate the case where the message was never sent from the one where it was sent but not received (because the receiver quit before that message arrived)?

---

Drop Message.vi generates a trace.  I should probably note that in the course.