"Pre-Run" Code Execution

Question

Hi,
    This is sort of a detailed question, so i'll try and explain it as best I can. So what I have is a text file, which contains a large list that I am parsing through regular expressions. I would like to take this list, place it in a combo box, allow the user to select their item and then continue. Now to achieve this, i've created two VI's. The first parses the text file and the second does something to the input. Now what i'm trying to achieve here is to bring this down to only one VI. I'm trying to write a "toolkit-like" bit of code for our company and the less VI and user understanding it requires, the better. So i'd like to be able to have a VI that executes a bit of a code prior to run so that the user can select the item they would like, and then hit run.  If you want a good example of what i'm trying to achieve it would be similair to the selection of GPIB devices on the VISA references VI. If this is unachievable then my next question would be how do i create a subvi that populates a combo box that can be made available to the parent VI. Currently I get the list of items from the sub-vi and then populate the combo box through a property node in the main VI. When i try moving the property node and combo box inside the sub vi and then connecting the combo box control to the connectors and creating a control for it in the parent VI it doesn't operate properly. Thanks for any help!
Regards,
Ken

Answer 1

Hi everyone,
I've expanded upon these ideas to make them more convenient and easy-to-use for client programmers. Functional global variables are very powerful programming techniques, but they have one slight draw-back. A functional global can execute any number of different cases, but only some of the inputs are relevant for any given case. In Dynamik's example above, for instance, the Read case requires a ComboBox refnum to be input, but how is the client programmer to know that the Execute case doesn't require this input anymore? Also, how is the client programmer to know that the ComboBox refnum IS required in the first case? You can't set the input to required unless it's required for ALL calls to the functional global, which doesn't make sense.
You can solve this problem by creating a polymorphic VI whose instances all wrap the functional global and call different cases of it. For instance, in the example above, you could create two VIs that call the Read and Execute case of ComboBoxTool.vi respectively. The Read-case VI would select Read for the enum and have a ComboBox refnum input that's REQUIRED. The Execute-case VI, on the other hand, would select Execute for the enum, but would only wire a constant into the ComboBox input. This way, when the client programmer calls the Execute case, there's no possible input for a ComboBox refnum, so one's obviously not needed.
Why did I specify that you should wire a constant ComboBox refnum into the ComboBoxTool.vi input for the Execute-case? This allows you to modify the original functional global (ComboBoxTool) to have ALL its inputs required. Since the client programmer never accesses the VI directly, this is ok. You can then eliminate some of the overhead of calling an extra subVI. Because LabVIEW knows that all of the inputs for ComboBoxTool are required, it doesn't ever have to check if valid values were input to the function before calling it. It knows that values are there to use. This saves some execution time.
I've attached the example below. The only thing it requires is a little knowledge on how to build Polymorphic VIs. Trust me, once you've built your first one, it's really simple! And since all the cases are very similar (they all call the same functional global, just with different inputs), you can copy them quickly and modify the connector pane. This technique will give you greater control over what the client programmer sees and uses, and it won't require you to upgrade to LabVIEW 8. (If you do have LabVIEW 8, however, you can extend this technique and embed the functional global, it's polymorphic wrapper and all the instances into a Project Library and set the original functional global to Private. This would make it impossible for the client programmer to access it directly!) Take a look at Dynamik's example modified below.
Jarrod S.
National Instruments
Attachments:
Polymorphic_ComboboxTool.zip ‏44 KB