I use case-selectors with a strict-typed enum Mode control to leverage subVI functionality. For some VI's that get called a lot (such as an LV2 global), there may be many many instances of the VI. Currently, there are two ways to find a specific function call that uses the VI and a moding constant:

• Search for the VI, then look through every instance until you find the right one
• Search for the enum constant, then look through every instance until you find the right one

Where this lacks heavily is finding a particular enumerated function--both methods above find all functions. For example say I have a VI with three modes:

• Load References
• Save Values
• Get Values

If I want to find the one instance where I load the references, I may have to search through a dozen or so instances of "Save Values" or "Get Values" before finding the one enum constant designating a "Load References Call". And actually in my case, the statistics are worse than that as to how many I have to look through.

The short of it: It would be nice to have a method to search not only for an instance of an enum constant, but for the instance of a particular value of an enum... like being able to select the object in the Find box and then also being able to get a dropdown list of values to select from (or an all encompassing "All Values", similiar to property nodes.)

I wanted to add a note to this particular post because somewhere along the way I discovered that even though you can't look for a particular instance of enum, you can manually type in the text and LabVIEW will find that text for the instantiated enum--meaning you can find all text that is identical and then pick the items off the "found" list that are actually enums.

While it would still be nice to have selective search capabilities, it works for now doing a text search.

I have debugged code written by others that used "naked" functional LV2 globals (not placed inside wrapper VIs to hide the call mode selection and input/output routing). I find it a real pain, as you have described, to search for all instances using a particular call mode, in addition to reverse engineer which inputs and outputs are associated with each call mode. Here is the solution: for each calling mode, create a wrapper VI. It is then very easy to search for the wrapper VI instances. Also, users of your functional LV2 global will always know which inputs and outputs are relevant to a specific call mode. The collection of wrappers can be thought of as the API of your component.

That's an excellent idea Jim--well thought out and something I hadn't considered. I would still like to be able to search by enum instance of course

The only concern I might have with making wrappers is trying to remember when exactly LabVIEW makes copies of data. If I had a large amount of data (big array or something) I was passing out of the LV2 global, would there be another copy made because it gets passed out of the wrapper also? Or just one copy made?

Either way, having LV2 wrappers for each function sounds like a great idea.

Early versions of LabVIEW can make copies of data where it isn't necessary. But at least since 5.x it does not generate data copies when merely passing out a variable from a subVI to its caller.
This does of course require a few clarifications:

If your frontpanel is open, then LabVIEW will create a copy of the data for the internal data buffer of each control. This is logical as the control needs to maintain its own copy to be able to (re)display the data as needed.

In LabVIEW 5.0 and 5.01 (and probably 6.0) where some issues where passing out arrays stored in shift registers could either create unnecessary copies or much worse under certain circumstances: reuse data from earlier loop iterations which resulted in wrong behaviour. This is however not a problem which would appear in a wrapper VI but in the actual LV2 style global itself, so creating a wrapper had no influence on this nor a worse performance.

In current versions of LabVIEW passing in large arrays into subVIs to be worked on in there (and preferably through shift registers in the subVI if a loop is present) and then passing them out of the subVI again to the caller does not create data copies at all, unless absolutely unavoidable because of the data manipulation inside the subVI. So this architecture is much more performant than simply branching of from the array to be passed to a subVI for operation on that array. This is since branching a wire to be passed to a subVI will have to create a copy of the data, while by simply passing it though the subVI where no branches of the wire occur can completely reuse the original buffer.

Rolf Kalbermatter