Create FGV Wrappers

[Hooovahh]

At the last user group meeting we were talking about functional global variables, and action engines.  We talked about how if you have an enum method on the input that you usually end up with other inputs or outputs that aren't valid for certain methods. And that another layer of VIs can be used to help clean up the interface.  So that you have a VI for each unique value of the method enum input.

So I wrote some scripting code which will do this.  Given a path to a VI that has an enum on the connector pane, the attached code will generate the wrapper VIs where each VI has a constant for the new unique value of the enum.  From here you can remove unused inputs, change the icon, or changing it how ever is needed to help make the accessing VIs easier to use.  Included in the zip is an example VIG that can be used to demonstrate how it works.

[crelf]

Nice work Brian! Is this already on LAVA?

[Hooovahh]

Crosspost

[Paul_Torek]

Thanks Brian.  I like the fact that I can search for one particular case, e.g. Write Values To File.  "Where, and how many times in the overall project, do I do that?" I often wonder.  This will simplify that business.

[Hooovahh]

Yeah as others mentioned in the last user group meeting you can search on the enum string so you can search for the text "Write Values To File" but obviously you may get more results than just from that enum.  If I have a FGV with a method of "Init", "Read", and "Write" searching for Read as text in my project will return way too many results.

[ASTDan]

I would like to ask a question to this converstaion.  When is it appropiate to use FGV (Action Engines) and when is it apropiate to use OO?  One case I can think of is you would want to encapsulate your data using a FGV.

I would be curious what peoples thoughts are on this.

[VItan]

Here are my thoughts:

I actually NEVER use LabVIEW Action Engines anymore.  I believe that a LabVIEW Action Engine is nothing more than a monostate class that is controlled by the VI Server with an extremely clunky interface.

Having a "single" VI with an enum determining which block diagram you are really interested in using sprawls the inputs and makes it impossible to properly set required / recommended / optional for them.

If you simply create a monostate class yourself, then you have everything that an Action Engine provides, with the additional benefits that it seems users are trying to receive by going through these "FGV Wrapper" workarounds: Individual methods that are searchable and with limited and properly configured input terminals.

[JLMommy]

I think there is still a place for both although I personally tend to use OO more.

Here are my thoughts on using one over the other...

Use an AE if...

1.  The customer doesn't know OO and they may need/want to modify the code

2.  You are looking for readability for a larger audience

Use OO if...

1.  The customer understands or requests OO

2.  The customer doesn't know OO and you don't want them to mess with the code 🙂

[ASTDan]

Becky that is a great explaination.

Thank you very much!

[Hooovahh]

FYI there have been some improvements over on the LAVA discussion.  The last version I posted now creates a polymorphic VI and adds all the VIs to it.  This is handy because the polymorphic selector is the name of the method and even if you use the same icon in all the VIs it is clear which one is being called.  It also makes a library and adds all the VIs to it, making the the core VI private while the rest of them to public.

https://lavag.org/topic/19114-create-fgv-wrappers/#entry115178

There was also a post after mine which tries to see what controls aren't being used in each VI and delete those from the front panel.  This doesn't quite work right in every case but some might find it useful.