Front panel updating

[jfalesi]

Wondering if there are best-practices for updating the front panel in an OO message-passing application. The front panel updater will likely be a separate thread, but I'm not sure if the indicators should be updated individually upon reception of an "update" message, or if all indicators should be owned by a "GUI" object that is passed around as a message, and each thread adds its own data to it.

[altenbach]

You probably need to add significantly more detail than that.

[Kyle97330]

You might consider it to be part of a model-view-controller architecture, with what you are talking about being the "view".

There are plenty of web-based references to that architecture that do not specifically mention LabVIEW.  If you have an active SSP you should be able to watch this LabVIEW-specific one from the Center of Excellence:

https://education.ni.com/center-of-excellence/resources/1162/improve-your-qmh-with-principles-from-t...

Basically, instead of thinking of it as something that sends a message saying "please update this indicator", think of the front panel as being something that gets messages containing ALL changes to program state, relevant to the front panel or not, and then in that code module it decides what to show.

As a general note for best practices, whether you use this model or not, keep in mind that writing directly to an indicator terminal is as close to instantaneous as LabVIEW can get, writing to a local variable is not that fast but still pretty fast, but writing to a property node for a front panel control (value or otherwise) can be dreadfully slow (relatively on a computing level, not a human level...) because it waits for the UI thread to do a full refresh (usually 1/60th of a second or so).  So you will want to minimize use of property nodes, and if you ever do need to use them in bulk, use the "Defer updates" property of the front panel to do them all at once instead of one at a time.

[jfalesi]

Thanks, that's helpful. Do you know if there's code to go along with this presentation?

[Kyle97330]

---

@jfalesi wrote:

Thanks, that's helpful. Do you know if there's code to go along with this presentation?

---

I don't think so, but did you notice that the "download" button downloads the powerpoint slides?  Might help if the video is blurry in places.

[jfalesi]

The presentation is clear but I'm struggling with the architecture. For example, are the model, view and controller three different loops? I understand that the model (business logic) can be separated from the controls and indicators, but do the controls and indicators go in the same loop? If not, are there different tabs or subpanels for controller and view? Or can they be intermingled on the same panel? In other words, where do the controls and indicators live? I'm down with event handlers and message-passing between loops using queues/QMH/channel wires, but I always have trouble deciding who should live where.

[jfalesi]

The presentation is clear but I'm struggling with the architecture. For example, are the model, view and controller three different loops? I understand that the model (business logic) can be separated from the controls and indicators, but do the controls and indicators go in the same loop? If not, are there different tabs or subpanels for controller and view? Or can they be intermingled on the same panel? In other words, where do the controls and indicators live? I'm down with event handlers and message-passing between loops using queues/QMH/channel wires, but I always have trouble deciding who should live where.

[jfalesi]

A related question is, in the "view" loop (which I'm assuming is where all the indicators are updated), if you're using an OO message design, each message's "do" VI would just update the indicators that are part of the message. So, should the "do" VI take the entire indicator cluster as an input, replace the data in question, and then output the entire cluster? Is there an existing OO message passing framework template? I've seen the message handler/state machine examples that use queues, but I discovered channel wires and I'm never going back... can class objects be passed over channel wires?

[Kyle97330]

I don't know of an existing framework that implements this exactly.  The closest one is probably the MQTT broker except that it runs over TCP/IP instead of typical LabVIEW messaging, which is a bonus if you want to have several applications using it all simultaneously but also not as fast if it's just for one standalone code module.  It could be there's another framework that's closer.  MQTT uses a publish/subscribe message pattern, so your main Model code would publish everything in State data and subscribe to Controller commands, your Views would be subscription only to just the parts of the Model's state that they care about, and the Controller would publish commands and subscribe to nothing.

I think that for something like this architecture in LabVIEW it really depends on how big and how often what would be defined as "state data" updates as to how complex you get.  The bigger the amount of things in state data and the more they update, the more complex the architecture gets to ensure you're not rerunning the same code hundreds of times in a row that either apply the same visual changes over and over, uselessly changing nothing, and not changing your states 1000 times a second so that the View tries to update faster than a human can register.

[JÞB]

Model: essentially an abstract parent class of view. 

View: a Model implementation of a specific front panel.

Controller: dynamically dispatches View update methods

Ideally,  the Model will launch the View specific UI. And have a DO(nothing) method. The View specific init would return a ref to its data and FP. The controller should A) update the View private data and B) periodically push the View Private Data to the View UI at human eyeball speed.