As Teased from this thread
This Nugget has been a collaborative effort inspired by a forum thead started by Richard Sorrellis. You all know him As Broken Arrow. I have enjoyed working with him in fleshing out an example of the solution we discussed in This thread
In this nugget Broken arrow and I will introduce a twist on an AE (If you haven't read the famous Action Engine Nugget yet you may want to follow the link in my tag "Required_Reading")
Creating and maintaining reusable GUI componets has been a somewhat bothersome over the years since each GUI essentially owns the copy of the controls that are on them. Action Engines allow us to offload the responsibility to updating Front Panel objects to a GUI controller through VI Server Referances but at the cost of updating the Value properties through a property node. In highly complex GUIs this slower method of updating values can chew up a lot of time.
With a few tweaks to a standard Action Engine we can create an AE with a single FP object (or group of related objects) visable on the front panel. This will be the private data that is maintained on the AE's Shift register and we will use a sub panel to show the GUI the value withou the GUI knowing anything more than a referance to the AE.
So now that we are back to wiring directly to the terminal what else have we done? There is no reason that we can't use the exact same object in another procect's GUI and maintain form and feel across applications we deliver.
So what shall we calls these GUI Element Resource Modules? I'm just calling it a GERM- a seed to grow a GUI by adding standalone components that take care of themselves without bothering the GUI
The Attachment contains a Source distibution a a GERM and a Example GUI and GERM Exercisor saved in LabVIEW 2011
Open the Library and run the highlighted examples.
I'm Sure Broken Arrow will chime in soon to express how this type of creation has helped his code improve.
@BA Great working with you!
The catalyst for this Nugget started when I was investigating “wireless” methods for updating GUI elements; specifically, a “status bar” string display that most of my programs have. I write to this string indicator in many places – deep in subvi’s, within sequencers, while starting up, shutting down, etc. This entailed “digging down” into subvi’s with a Queue or Notifier reference, and wiring it through state machines and so on. For a non-critical item (the status bar), this seems like a lot of bulk on the diagram.
Using a reference to the Queue reference (which is programmatically indexed from an array of references) allows wireless updating to the string, but again, the bulk and performance hit nags at me.
Turning to the forums for some inspiration, Jeff Boher posted a response about an AE/subpanel method. I have used AE’s extensively, and I was expecting someone to mention them, but it was the subpanel that got my attention. A subpanel with only one control? Sounds strange at first. But consider that the only real overhead should be when the program loads an extremely simple VI into the subpanel. From then on, you are writing to the terminal.
I took Jeff’s idea and restructured a large program with the AE/subpanel method for the status bar. It worked great, with much less bulk and dodgy bits around the diagram.
Take a moment to review the examples, and let us know what you think.
a.k.a. Broken Arrow
Didn't get my demo posted before time ran out.
Attached, find example. Open Project. Run the VI "SubPanel AE Demo_2.vi"
The subjet of off-loading FP updates does come quite often and, Subpanels seam to be overlooked for handling blocks of code updating related objects. By sheer serendipity I ran into a new Project that required a summary display for a network of senors and a detailed display for a user selected sensor. The original developer (no longer on the project) had intended a seperate GUI as a floating box and the customer did not like it. Sucking the detail display vi into a sub-panel and launching the display via a " Fire-n-Forget" Asynchronous-Call-By-Referance was a simple way to refactor the GUI WITHOUT changing the GUI controller. Between the Silver GUI Upgrade the demonstration of SubPanels and the ACBR (Hey, You can do that with LabVIEW now!) The customer is getting what they want and is now happy with the product and progress being made.
Richard's question certainly got me thinking along Sub-panel enbedded GUI objects and this became an excellant method to quickly turn a failing project around and recover a customer's confidence.
I've done this in the past also.
It gets really interesting when you combine this with Objects with their own defined visual interface.... You end up with self-presenting objects which work really well as plug-ins. By defining a framework of events to coordinate the Object and the host program you get a really nice expandable plug-in architecture.
This allows you to deploy not only new CODE after compilation in the form of new objects(classes, I always mix up the two) but also new UIs (to a certain extent).
I came in early to look before starting work but realized I don't have LV 2011 on a machine hear yet so I will have to reply based on the words only.
Although I have not taken the approach of using the AE as the GUI element (I would like to see some screen shots of the code) I have used sub-panels to avoid the overhead of property nodes to update very busy GUIs. These work out very nicely since the code complexities are limited to only those factors that are involved with the GUI elements in question.
I had previosly posted about these in the context of "Docking" with a simple demo appearing like this;
As I understand your GERM, (you are placing all of the code associated with a GUI in a single VI) this is similar in that I know exactly were to go to tweak the display.
In actual use it played like this
There are more screenshots of that app here.
But I really need to look at your code to figure out if I am following you correctly.
Now to Shane's point about doing something similar in a LVOOP context.
My early attempts at plugins using LVOOP were sadly lacking but one of my more recent involves rendering ultrasound in 3-space. Since the surfaces we will be scanning can and will vary from one implementation of the app to the next, the surface rendering is done using user selected plug-ins and each surface has its own set of configuration settings. So i need part of the GUI to allow configuing widgets that I know nothing about at development time.
So each of the Plug-in inherit "Load in subpanel" Unload form sub-panel" "Refresh" and "Save Yourself" methods. Load and unload shows/hides the config screen and "save Yourself" saves the current configuration. I only have one screen shot handy showing the sub-panel being used to adjust the mapping of data onto the web of a train wheel (in this case). The web being shaped like a sombraro, required special treatment, see subpanel in tab control on left side of this image.
But again, this is just my attempt to share my experience with similar approaches. I may not get to 2011 soon (my projects span years in many cases, updating a LV 8.6 today) so I just have to appologize for responding without looking.
Again thanks for the Nugget!
There are 2 different approaches here. Jeff's uses the AE as the UI for the SubPanel. BrokenArrow's uses a wrapper around the AE.
There is potentially a serious issue using Jeff's approach. His example is quite simple, so it is not very evident, but having the AE be your UI can cause lag issues in your code. If you have a more complicated UI, your calls to the AE have to wait for all UI activity to complete. I have a status window I use occasionally. It updates in reverse chronological order, and depending on status, changes the color of each entry to indicated normal, warning, and critical. LabVIEW is not very efficient in building in this string, since I have to recreate it every time. So, if I use Jeff's approach, every time I post a message to the status, my call to the AE would have to wait for that string to be rebuilt. And every other piece of code waiting at that time to post a status message would also be waiting for the VI to become available.
While BrokenArrow's example is simple as well, you can see the potential that his AE wrapper is what would do all the heavy lifting, freeing the AE to be available to be updated, etc. This also allows the UI to catch up - if I got multiple status messages, I can combine them in one call, or I can drop the old ones because I only need the last message.
If it were me, I would go with the UI wrapper than trying to build your AE into a UI.
I also didn't mention the potential ramifications of your AE being pushed into the UI thread if your AE is your UI.