Putting the user interface front panel into a subvi

[cebailey]

>The Traffic Cop Behind the Scenes
A detail I have not mentioned up until now is that AEs should be implemented as VIs that are not reentrant***.

Well, that didn't take long!

[nathand]

---

cebailey wrote:

I appreciate the reasoning behind using a queue. But I don't quite picture it yet - what are the queue elements? Maybe a cluster that contains the data value to be passed and a reference that identifies what control it is coming from (in Ui>Main) or going to (in Main>Ui)? Or am I just going back to the disadvantages of reference objects with that idea? There has to be some mechanism that points at a control, right?

---

From the main to the GUI, the queue element could be as simple as a cluster of the data to be displayed, then put all the logic to determine how to display it in the GUI VI.  From the GUI to the main the queue element will depend on your application.  A simple implementation might be a cluster of an enumeration, a numeric, and a boolean, where the enumeration specifies what change to make (start, stop, update a particular value) and the boolean and numeric are the new value to update.  It's a producer-consumer system in which the GUI acts as the producer and the main is the consumer.

By the way, one more disadvantage of using control references is that they're slow.  Writing data directly to a front panel terminal is much more efficient, and sending data through a queue to the GUI VI lets you do this while still keeping the GUI separate from your main program.

[cebailey]

>From the main to the GUI, the queue element could be as simple as

>From the GUI to the main the queue element will depend on your application.

So the items getting passed in the two queues are actually meaningful to the programmer. One might mean the pressure has changed to 80. Another might mean the user wants to stop the fill operation. Generally, this doesn't have anything to do with refs, or at least doesn't have to. But it has everything to do with the ways the program's components respond to a change.

I like this. Other than the queue doing its thing behind all the block diagrams, everything that moves in this picture is dataflow on a wire.

[DFGray]

My queues in both directions are typically a cluster containing a command and data.  The command is usually an enum, but I use strings sometimes.  The data is almost always a variant, to allow me to pass anything.

Depending on the architecture of your GUI, you may want to use a user event instead of a queue for the Main->GUI communication.  This allows the commands to seamlessly fit into the event structure of the GUI.

I also run both the GUI and main VIs as top level VIs.  They are launched from the launcher using the Run method with Wait Until Done set to False and Auto Dispose Ref set to True.  Only the GUI actually shows its front panel.

[cebailey]

How do you run the top level Main.vi without showing its front panel?

[mikeporter]

The thing to remember is that in the LV world, there is a difference between open and visible. Using the Open Front panel method you can open a VI's front panel as Hidden. In that situation, the VI's front panel is not visible, but it is open. This is useful when you want to have a VI running in the background as a hidden VI does not show up in the taskbar.

Mike...

[DFGray]

When you launch a VI using the Run method, the front panel state (open/closed) will depend on the VI properties (you can make the VI automatically show its front panel or not) and whether or not you used a method to open/close the panel.  I usually use methods to open and close the front panel because it allows me to get the front panel into a known state before it is shown.  If you need more details, let us know.

[Ben]

---

Peter S wrote:

...

Personally I think it is the best way to use the main VI as the Front Panel VI, containing al the necessary controls and not too much functionality.

....

Peter Schutte

---

I agree if the app is simple.

Complex GUIs can become very difficult to manage if every control for every screen/view are on a single FP. Prior to LV 7 (?) we could not have more than 550 FP objects (One of my customers found this out) so we were forced to use more than one screen.

When ever possible I like to carve up GUI screens into pop-up VIs or put them in a sub-panel.*

Ben

* I am writting a Nugget on this subject that I hope to release soon as part of a new Web-site I will be building.

---

 CE wrote

>The Traffic Cop Behind the Scenes
A detail I have not mentioned up until now is that AEs should be implemented as VIs that are not reentrant***.

---

This is a quote from my Action Engine Nugget which was linked by Dr Gray earlier in this thread.

Message Edited by Ben on 01-16-2009 08:16 AM

[cebailey]

>This is a quote from my Action Engine Nugget which was linked by Dr Gray

Yes, and you and others here are turning up all over the place, as I follow links and try to dig back through similar trains of thought. The difficulty is that I often read one of these before I have the context to make sense of it, and the content there flutters away from me like a lonely sparrow. Some of these things breeze by a half a dozen times before it looks like the answer it really was all along.

But the good news is that finding the stuff in the first place seems to work pretty well. It has been a long time since somebody posted a list of resources none of which I have already found.

So I print the stuff out like it's made of gold, and leaf through these things while I feed the cats or sit in a waiting room or wait for a soldering iron to get hot. Eventually they start spontaneously crosslinking.

In astronomy there are competing theories about the ultimate destiny of the universe, whether it will expand forever or start shrinking again some time in the distant future. And the big question is, will the number of competing theories about the ultimate destiny of the universe increase forever, or will they start becoming less numerous again some time in the distant future.

So it is with LV, and putting the GUI in its own VI, and testing controls to see if they're wired, and, and, and...