Community Nugget Series: Application Development: Installment 2- The GUI and FP object encapsulation

[MikeS81]

Hi Ben,

here it is.

Mike

Edit: Please copy the Demo\Files folder from the 2010 version.

[Ben]

Sorry for the delay but I do want to squeeze this in before I head off again...

Jeff,

That example of a GUI controller is a bit more robust than I expected for an example (at first glance) but then after examining it, realized that litle bit of extra conplication is an excellent motivation for a GUi controller.

The Complication: Views change for various users.

Implementing all of the control settings for each level of access means that there could be as many version of "Show" as there are defined acces levels. To implmenet and then maintain this functionality would be challenging to implement and a nightmare to mainatin.

Note:

Not using a GUI controller for applications of this type sooner or latter gets you into a situation where your phone rings and the customer is saying "blha blah blah changes blah blah great blah blah BUT if yo udo this then this then it is..."

By using GUI controller GUI problems are either in the GUI controller (and its sub-VIs) or something that uses the GUI controller.

Now for some generall comments and questions since I'd like to hear what others think...

1) When dealing with multiple refs and property nodes I often (when there are tree or more depending on how the diagram reads) will use a sperate "Unbundle by Name" fore each property nodes to accomplish two ends.

a) Unbundle node "self-documents" which control is being actd on.

b) Make it easier to find the property node that without chasing a wire across the srceen.

Note: These are just my analy-retentative preferences and serve no purpose other than stated above.

From all of my reading multiple unbundles don't result in poor performance by the time LV unravles what you want and optimizes the code.

2) I avoid rebundling ref after using them. The ref is not changing (I like to learn about them if they do, type-cast as a U32 and see they say the same once teh code runs).

3) Now to your "Class" comment

You have used a code construct that is very similar to an Action Engine (it keeps it private data in the shift register and access to that private data is only possible through calls to the sub-VI) I have never read about, I believe I mentoned in passing in my Action Engine Nugget.

The code construct that I am refering to is the loop in the sub-VI may iterate more than once depending on the method invoked. Setting the permision method will invoke the "show" method after completing.

Q1) Should we still call this an Action Engine?

If not what scan we call it?

Q2) Have any of you implemented a similart critter? Yes I have. I had to implement on tht could potential execute about 15 states depending on the siutation.

If you did why did you choose that construct?

Comment:

You know... it you create wrappers for the calls to the GUI controller, put them all in a library, you can have something that resembles LVOOP by only creating wrappers for the calls that are allowed so that for example "Show" can never be called directly since there is no wrapper for it.

I am curious what others know and can say about any of the above or any suggestions from others on how they manage large GUIs.

Thanks again Jeff!

Ben

2)

[JÞB]

[Ben]The Complication: Views change for various users.

Implementing all of the control settings for each level of access means that there could be as many version of "Show" as there are defined acces levels. To implmenet and then maintain this functionality would be challenging to implement and a nightmare to mainatin.

Note:
Not using a GUI controller for applications of this type sooner or latter gets you into a situation where your phone rings and the customer is saying "blha blah blah changes blah blah great blah blah BUT if yo udo this then this then it is..."  By using GUI controller GUI problems are either in the GUI controller (and its sub-VIs) or something that uses the GUI controller.

[Jeff] Working with Software Engineers specializing in LabVIEW development you get a much different answer than when working with Test Engineers!  
OK that's the tounge in cheek answer.... but, it brings up some interesting points.   Let me elaborate somewhat (this could require some duct tape.) "Components" of a system are defined by the system "Framework."  There is a school of thought for Component based programming.  "Components" in this context, encapsulate a set of related functions (or data).  Taking Show Hide Controls.vi as an example.  With this construct I encapsulated the set of objects the operator can select to change the state or state flow of the system.  This is a highly selective list and we can say there is strong coupling between these objects. The Show method specifically denies USER access to these objects without permission by checking the state of the system and a list of user permissions.  The Show method usage is then "Call whenever Testing? changes or  Pemits changes.  Were these events exposed in this example - no COULD they have been? YUP! and I'ld agree that would be more robust!  I copped out and wrote a KISS component demoing the function with VI server Refs and no dynamic events.  Suppose "Testing?" changes type to something more complex than a BOOL?  Say "Status" <as string> and "In Test Dev Lab?" as bool,  I have exacly 1 state to change.   I can also add other methods that depend on the new "system state" In Test Dev Lab?".  "Failing in Lab" might prompt a new method setting all remaining Breakpoints and displaying additional information for the dev team.  By encapusatling just these special "State Flow" controls I can easilly debug how I got into a improper state for the system.  

The Flip side-  these objects obviously belong to a larger group "FP objects"  If I have a requirement "allow user to move all objects" I need a parent component that reaches into this component with a method to disable all these objects, show them all and allow dragging. (and probably save the settings).  My "move objects" method becomes more complex (but allows special handeling for this sub-class like, dissable the controls)  and more difficult to debug as the method has "overrides."

Ben's GUI controller is not without merit-  really only a change in scope of encapulation!  The reliance on unbundle by name to aid identifying which object or group of objects is being acted has a simillar effect of increasing the coupling of related objects as the approach presented here.
 
[Ben] You have used a code construct that is very similar to an Action Engine (it keeps it private data in the shift register and access to that private data is only possible through calls to the sub-VI) I have never read about, I believe I mentoned in passing in my Action Engine Nugget.The code construct that I am refering to is the loop in the sub-VI may iterate more than once depending on the method invoked. Setting the permision method will invoke the "show" method after completing.
 
Q1) Should we still call this an Action Engine?  
[Jeff] I believe this contstruct is an Action Engine-  of a special case.  Wrappers would present it as a "Pseudo Class" or it could be written very similar as a Class.  The key differentiator from a "Classic" Action Engine is not that it can loop more than once but that it abstracts the actions to perform on the object(s) in the referance (Resource)  within the system.  I use the same construct for Hardware resources too!  One benifit I find is the ease of finding them in either  "Tree.vi" or in the Heirarchy view "This resource is here and it has these abilities" just shows in your face with Help on.  The Icon style and VI documentation are a subset of the practice.  Within my internal lexicon I simple call them "Modules." 

[JÞB]

Hmmm... the subject of "Modules" showed up in a thread here

the OP was having some dificulty maintaining a VISA session through an event loop where the resource was only used in a few of many cases.  This reminded me that I had mentioned here that I use the "Module" construct for hardware and whipped out a quickie example encapsulating base functions for the 34401A since that driver that ships with LabVIEW.

I'm wondering if anyone else uses similar methods to encapsulate hardware functions.

[RavensFan]

Yes.  I will do something like that using an action engine.  That way I don't have to worry about the VISA wire everywhere that I want to do some action with my serial port.

Though lately, I've been going a step farther and using it a way that I'm calling it a serial comms engine that I launch as a subVI in parallel to the rest of my code with nothing depending on it.  Basically a daemon configuration.  Then I will just use queues to pass data and commands into the subVI's while loop.  Init, read/write, close, and shutdown.  The shutdown or exit command being the one that ends the while loop so that the program can end.

[JÞB]

---

@Ravens Fan wrote:

Though lately, I've been going a step farther and using it a way that I'm calling it a serial comms engine that I launch as a subVI in parallel to the rest of my code with nothing depending on it.  Basically a daemon configuration.  Then I will just use queues to pass data and commands into the subVI's while loop.  Init, read/write, close, and shutdown.  The shutdown or exit command being the one that ends the while loop so that the program can end.

---

Interesting!   I've also used it to support independant operation as well add a named queue and the loop exit condition gets off the constant and a T from the close case