Actor Framework UI Communication

[CanadaGuy]

Maybe I'm blind, but I've been looking and I haven't found it. I think that I want a UI actor, and a bunch of other actors that do work, and display results or feedback in the UI actor front panel. Is this the right way to think of this? Can anyone recommend some reading material specific to handling UI and user interactions?

[McQuillan]

I've been using this toolkit from MGI and I really like it:

http://www.mooregoodideas.com/products/panel-manager/index.html

When using AF for a UI it is very common to use subpanels. I love them, they make for a very clean UI, I've implemented my UIs with drag and drop between the subpanels. The toolkit I linked, makes it very easy to manager all the subpanel references.

When you install the toolkit, it comes with come examples to get you started 🙂

EDIT:

Further to this, the use of helper loops in the actor core overrides are used to monitor front panel events. User events can be used to send data from the Actor Core to the helper loops.

Go through this guide: http://www.mooregoodideas.com/actor-framework/basics/AF-basics-part-1/

[OneOfTheDans]

I'm also new to AF, but here are some UI approaches I've seen/used. Obviously the ones you use depend on the application. Whether you need "a bunch of other actors that do work" is also not really relevant to the UI. Sometimes all the work can be done in your UI actor, sometimes many other actors are needed, it just depends what you're doing.

Generic GUI

First, if you don't already know, you make a GUI in an actor by overriding Actor Core. Your overridden Actor Core.vi will have 1 call to the parent (e.g. Actor Core message handler) and 1 Event Handler loop. Then you pass info between the loops by user events, control references, AF messages, queues, notifiers, or however you like.

Architecture 1

The simplest way is to do what you described. Make 1 actor that is a GUI & general application control (which can include worker actors, if needed).

Architecture 2

Another step after that is splitting general application control to 1 actor, the the GUI to another sub-class actor. The GUI will send-message-to-self to control the application. This is good if you plan to have different GUIs for the same core application.

Architecture 3

I've also enjoyed making mini-GUI actors. The actor just handles a small section of the GUI and it's fully contained. The top-level GUI includes the mini-GUIs via a subpanel. This is super maintainable for my application, where we have 6 exact copies of a GUI interface, but they all need to be running at the same time. I can switch between which one the user sees in the panel, but they're all running.

That might get you started. Hopefully some more experienced AF people will chime in too.

[paul.r]

---

@CanadaGuy wrote:

Maybe I'm blind, but I've been looking and I haven't found it. I think that I want a UI actor, and a bunch of other actors that do work, and display results or feedback in the UI actor front panel. Is this the right way to think of this? Can anyone recommend some reading material specific to handling UI and user interactions?

---

Sort of - generally speaking, you don't want your actors that are doing work to display the results to the front panel of another actor. You want the actors that are doing work to put the results of their work in a place that any interested component could grab and use it. This way, you can add multiple types of views, or loggers, or analyzers or whatever else you would like without having to change or update your worker actor. I do this through an implementation of the mediator design pattern - actors publish and subscribe to data topics they are interested in, with no direct ties between the producers and consumers and consumers of the data. 

There are lots of established design patterns that address this problem, links below.

https://en.wikipedia.org/wiki/Separation_of_concerns

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

http://www.labviewcraftsmen.com/blog/category/mediator-pattern

[CanadaGuy]

---

@paul.r wrote:

Sort of - generally speaking, you don't want your actors that are doing work to display the results to the front panel of another actor. You want the actors that are doing work to put the results of their work in a place that any interested component could grab and use it... I do this through an implementation of the mediator design pattern - actors publish and subscribe to data topics they are interested in, with no direct ties between the producers and consumers and consumers of the data. 

---

Thanks for the info. My learning right now is focused on what I believe is a pretty simple example, but I'm struggling to make it work. I would like to have the main UI Actor which handles the top level application. In the simplest form, it just has a text box which displays an event log. I would then like to launch a nested Actor and the sole purpose here would be to process incoming log data, periodically write the log data to the hard drive, and display the accumulated log text back in the text box in the UI actor.

From what I have read thus far, there are a couple of approaches:

1) What I have done so far, is pass references to the nested actor and the actor writes directly to the panel object. I know this 100% coupled and changes in one actor affect changes in the other. I would like to get away from doing this.

2) Use sub panels, where I suppose I would load the UI for the nested actor into a sub panel. I wouldn't use the text box in the main UI actor then. However, this still doesn't resolve the issue of core UI - Actor communication which I'll need in some minimal amount.

3) The decoupled or loosely coupled methods you described above. It isn't clear to me how to do what you've described.

I'll keep poking and reading to see what I come up with. Thanks for all the inputs.

[OneOfTheDans]

#2 sounds like exactly what you're looking for.

Make the nested actor Front Panel have everything you need (buttons for clear log, controls for write-to-disk frequency, resizing events, etc.). Then the UI caller just carves out space (via subpanel) for the nested actor.

[McQuillan]

I tried to comment a while ago, but there were some "technical issues" so I'm not sure if it got posted (sorry if this is a repeat!)

I've been using this toolkit from MGI and I really like it:

http://www.mooregoodideas.com/products/panel-manager/index.html

When using AF for a UI it is very common to use subpanels. I love them, they make for a very clean UI, I've implemented my UIs with drag and drop between several subpanels. The toolkit I linked, makes it very easy to manager all the subpanel references.

When you install the toolkit, it comes with come examples to get you started 

[paul.r · Accepted solution]

---

@CanadaGuy wrote:

---

@paul.r wrote:

Sort of - generally speaking, you don't want your actors that are doing work to display the results to the front panel of another actor. You want the actors that are doing work to put the results of their work in a place that any interested component could grab and use it... I do this through an implementation of the mediator design pattern - actors publish and subscribe to data topics they are interested in, with no direct ties between the producers and consumers and consumers of the data. 

---

Thanks for the info. My learning right now is focused on what I believe is a pretty simple example, but I'm struggling to make it work. I would like to have the main UI Actor which handles the top level application. In the simplest form, it just has a text box which displays an event log. I would then like to launch a nested Actor and the sole purpose here would be to process incoming log data, periodically write the log data to the hard drive, and display the accumulated log text back in the text box in the UI actor.

---

Sounds like the nested actor has three distinct jobs - process received data, display the processed data, and save the processed data. 

What do you mean by process the data? What is the source of the data? 

I would have the nested actor just process the data, then send it off for other actors to use. I use an implementation of the mediator pattern to manage publications/subscriptions, but you could use a simplified version of that by using a controller actor. The nested actor sends its processed data to the controller. The controller then passes the processed data to the UI and another actor that does the saving to disk. You can do this many ways - one option would be to have the controller actor have a 'subscribe' message, that a nested actor (the UI and data saver actors) send to the controller. They give a name (name of data they want to subscribe to) and their queue to the controller in this message, and the controller stores it in some way - a variant attribute table for example. When the controller gets that data (from the processor), it gets all the enqueuers of subscribers, and sends them a publish message. 

I dont think using subpanels gets you much in this simple example - use subpanels to keep individual components of your UI separate. In this example, if you wanted to display the data in a text box, and a graph, I would suggest using subpanels - make each component a different actor and put them both in a subpanel on the top level ui. 

[CanadaGuy]

---

@paul.r wrote:

---

@CanadaGuy wrote:

---

@paul.r wrote:

Sort of - generally speaking, you don't want your actors that are doing work to display the results to the front panel of another actor. You want the actors that are doing work to put the results of their work in a place that any interested component could grab and use it... I do this through an implementation of the mediator design pattern - actors publish and subscribe to data topics they are interested in, with no direct ties between the producers and consumers and consumers of the data. 

---

Thanks for the info. My learning right now is focused on what I believe is a pretty simple example, but I'm struggling to make it work. I would like to have the main UI Actor which handles the top level application. In the simplest form, it just has a text box which displays an event log. I would then like to launch a nested Actor and the sole purpose here would be to process incoming log data, periodically write the log data to the hard drive, and display the accumulated log text back in the text box in the UI actor.

---

Sounds like the nested actor has three distinct jobs - process received data, display the processed data, and save the processed data. 

What do you mean by process the data? What is the source of the data? 

I would have the nested actor just process the data, then send it off for other actors to use. I use an implementation of the mediator pattern to manage publications/subscriptions, but you could use a simplified version of that by using a controller actor. The nested actor sends its processed data to the controller. The controller then passes the processed data to the UI and another actor that does the saving to disk. You can do this many ways - one option would be to have the controller actor have a 'subscribe' message, that a nested actor (the UI and data saver actors) send to the controller. They give a name (name of data they want to subscribe to) and their queue to the controller in this message, and the controller stores it in some way - a variant attribute table for example. When the controller gets that data (from the processor), it gets all the enqueuers of subscribers, and sends them a publish message. 

I dont think using subpanels gets you much in this simple example - use subpanels to keep individual components of your UI separate. In this example, if you wanted to display the data in a text box, and a graph, I would suggest using subpanels - make each component a different actor and put them both in a subpanel on the top level ui. 

---

I have implemented a nested logging actor doing what I wanted, though I'm sure it could be significantly improved. It receives a message, attaches a time stamp, appends the new message to the log file, and updates the front panel of this logger actor. My gut tells me I should probably break this VI up into smaller chunks, but I figured that might be making a small problem more complex...all these actions need to fire in sequence each time a message is received, so I figure they belong in the same VI (that's for another discussion perhaps).

Using abstract/child messages, the root actor can request the latest log data, the logger actor delivers that, and the root UI actor displays the result. I did this step just to use the data request type message in a decoupled fashion, not necessarily because I will use the log data in the UI application.

I created a message in the Actor Framework Discussion forum on communication between two parallel nested actors, so I'd like to follow up there for the purpose of keeping AF discussions there.

https://forums.ni.com/t5/Actor-Framework-Discussions/Communicate-Between-Parallel-Nested-Actors/td-p...

[CanadaGuy]

---

@McQuillan wrote:

I tried to comment a while ago, but there were some "technical issues" so I'm not sure if it got posted (sorry if this is a repeat!)

I've been using this toolkit from MGI and I really like it:

http://www.mooregoodideas.com/products/panel-manager/index.html

When using AF for a UI it is very common to use subpanels. I love them, they make for a very clean UI, I've implemented my UIs with drag and drop between several subpanels. The toolkit I linked, makes it very easy to manager all the subpanel references.

When you install the toolkit, it comes with come examples to get you started 

---

I'm avoiding toolkits for the time being, just because I'm trying to wrap my head around some of the fundamentals. I have no deadline for things, so I'm trying to take advantage of the learning opportunities. I may look into the toolkits after I get a few AF rewrites using my new knowledge.

In my case, I want to reduce clutter in the UI actor, so using the logging actor front panel as a log window for viewing is going to be my approach for now. Once I'm comfortable there, I will explore the subpanel options. I have a couple projects that I expect to make use of sub panels heavily for simulation variants.