QControls and the Actor Framework

[TheQ]

Answering @SHowell-Atec's post located here.

A summary of his question, if I understood it correctly, is that he wants his QControl to send an Actor a message.  He modified the constructor vi (New [QControlName].vi) to have the Actor enqueuer as an input and adds the enqueuer to the QControl's data.  He asks is this the right way to do it?  Also, he asks, if the constructor and destructor need to be placed in a loop when using the Actor Framework.

For the first question: I think @SHowell-Atec has done it right.  The QControl launches an asynchronous Event Handler.  In order to get the Event Handler to send an Actor message, it would need the Actor's enqueuer.  There are two ways to get the enqueuer to the Event Handler.  The first way is to do it as @SHowell-Atec has done and add it to the QControl's data before the Event Handler is launched by modifying the constructor. 

The second way to do it is to include the enqueuer in the QControl's State Data and create a property to input the enqueuer. 

So why is @SHowell-Atec's way better?  If the enqueuer won't change for the life of the QControl, it would be better to make it required upfront and not changeable.  However, if you wanted the same message to be able to be sent to multiple Actors, (as long as those Actors can handle the message), you could do it the second way and make the enqueuer changeable.

For the second question, the QControl Event Handler can act as the Actor's helper loop if it fully contains the user interactions in the Actor Core.  However, in order to have the enqueuer available, the constructor must be launched in the Actor Core override and the QControl wire bundled into the Actor's data.  Then unbundled in the Stop Core override and the QControl destructor called to close the QControl Event Handler.

@SHowell-Atec, please feel free to add any detail or discussion.  Also, if you are able to share it later, that would be awesome too.

[SHowell-Atec]

Thank you Quentin,

I appreciate the feedback. Currently I will rely on the first option and pass the actor queue reference to the Q control through the constructor. I do not have a current situation where option 2 would be necessary.

Option 2 does bring up some pretty neat opportunities though, so I am keeping that in my back pocket. 

As soon as I have something nailed down I will gladly post screenshots of my code.

[SHowell-Atec]

Q, I have another question for you.

I am seeing some strange behavior in a custom Listbox control I made with the Q controls toolkit.

In my application I have multiple instances of the listbox control in separate UIs. Each listbox is an instance of the class and has its own dataset and memory space. 

However, it seems that when one of the UIs stops, and calls the close control.vi it is closing all instances of the q control of that class type. 

Not sure if that is expected behavior....oh by the way, this is in an actor framework project, but calling the STOP CORE vi of one of the UI actors should not stop the whole project, as it is the nested that is stopping, not the root.

***Update*** I have figured out the issue.

I was mishandling an error coming into the Handle Last Ack Core.vi from one of the nested, and it was being passed to the Main UI Actor Core and stopping the application. It was NOT due to anything in the Q Controls Toolkit.....

Simple mistake, oops!