GUI in seperate actor or as child of Controller

[A.Rohde]

Hi Guys

How do you normally go around the structure of the GUI(s) actor(s), do you make it as a seperate actor or inherit from the controller class.

I've tried both and I see pros and cons for both.

It seems most clean to have a seperate actor for the GUI but that also means that a lot of the methods in the controller class is just a wrapper. I.e. if you click on a start button to send a message to the DAQ module to start you would tell the controller to forward that message to the DAQ.

If I inherit from the controller that issue is resolved because the GUI then have access to the data of the controller including the references of the children. But actually it doesn't because those are instanciated in parallel to the GUI which means they have to be in a DVR for the child to access them. But if you put them inside of the DVR you save a lot of duplicated messages / forward logic. But I don't really like the DVR's that much for making the data available globally.

Hope it makes sense. What do you do with your GUI actors?

Thanks

Anders Rohde

[Oli_Wachno]

Hi Anders,

I am not quite sure, what you mean by controller class. But I can briefly describe the architecture I am using:

I have set up a state actor act as what I like to call controller. It is aware of the GUI state and keeps sending messages to other Actors making up the GUI itself. Communication is strictly hierarchical, so all Actors are using a communication tree. Information handling / dispatching is performed only by this controller, so there is no need to open backdoors like DVRs.

If you need data from another Actor, messages are the way to get it.

Didn't mean to restart the "which communication scheme is the best" discussion again

[A.Rohde]

My Design Options goes like this.

View

---------------------------------------

Controller

-----------------------------------------

Model A | Model B | Model C ...

If I use that approach and I want to send a message from the View to the Model A I would:

1a) Create a method in Model A (ActionX)

1b) Create a message for ActionX

2a) Create a method in Controller CallActionX

2b) Create a message for CallActionX

View can the use the "Get called enquer" to get Controller reference and send the CallActionX method which would end up in ModelA

This is as I have understood it the normal way of doing it for sending messages between two actors.

But I could also create a layout that looks like this:

Controller | ControllerWithGUI (inherits from controller)

-----------------------------------------------------------------------

Model A | Model B | Model C

If I go this way, my normal controller would start Model A, Model B and Model C, but then the child could do extra stuff. I.e. when the controller recieves a Data message it can foward it to however makes sense (i.e. filelogging) but then the child can extend this and also update a graph. My original though was that this was a much neater way to do it, though while trying it out I found out that the child did not have access to the data in the actor core of the Controller class.

The only reason why I got this to work and can get the reference to ModelA is because I've also made those references available through a DVR in the controller class. So the method that gives me ModelA's reference is getting it from the DVR.

I'm not really sure if I like this or not. It simplifies things a lot but could also give some problems.

So my main question which the thread is just to see if anyone else though of a nice way to minimize overhead in the controller class. Or if everyone is making the View as a seperate actor only linked to the Controller through messages.

Any tips is much appreciated

Best Regards

Anders

[justACS]

Hi Anders!  Nice to see you posting here.

How do you normally go around the structure of the GUI(s) actor(s), do you make it as a seperate actor or inherit from the controller class.

I've tried both and I see pros and cons for both.

What I teach in the class is to treat the View and Controller as a single UI actor, because LabVIEW front panels don't make it easy to differentiate.  (I am assuming you are using Controller in the Model-View-Controller sense.)  So split off the model code into an actor, and all the UI elements into another actor.

I further recommend that you create an abstract parent for the UI actor that defines all the messages the UI will receive, but leaves the implementation to its children.  This lets you define the relationship between the Model and the UI, while allowing you to change the UI later as needed.

If I inherit from the controller that issue is resolved because the GUI then have access to the data of the controller including the references of the children. But actually it doesn't because those are instanciated in parallel to the GUI which means they have to be in a DVR for the child to access them. But if you put them inside of the DVR you save a lot of duplicated messages / forward logic. But I don't really like the DVR's that much for making the data available globally.

Never do this.  Ever.  There is no need to use a DVR to communicate within an actor, and it will buy you all kinds of trouble.  Your UI actor core will have a loop that handles user events and front panel updates - typically an event structure, as shown in your second post.  (We refer to these additional loops as helper loops.)  Use messages to pass data from your helper loop to the UI's message handling loop, which can then pass it on to your model actor.  Yes, this means you are duplicating messages, but this actually gives you more modular code.  If you'd rather avoid this, have the Model launch the UI, in which case you will have access to the Model's enqueuer when the UI's Actor Core starts, and you can send messages directly.

If you need to update a front panel element (and who doesn't?), create a user event for each update type you need to do.  Add the update code to your event structure, generate the user event in a method of the UI, and make a message for that method.  When the Model needs to update the UI, have it send that message.

[A.Rohde]

Hi Alen

Thanks for your help and feedback.

Glad to just hear how everybody else is doing it. I'll continue to keep my GUI in a seperate actor and will start to implement a GUI_interface actor as you proposed and have my different GUI_implementations to inherit from that.

Best Regards

Anders Rohde