"Pre-Run" Code Execution

[Kenneth.Miller]

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

[kehander]

I'm not sure I understand completely, but could you possibly just use a state machine (or sequence structure if you want something simpler) ? Put the text file parser in one state (or frame), and the rest of the code in the next one.


As for the combo box problem, what if you passed a reference to the combo box to the subVI instead of moving the property node?

Message Edited by kehander on 03-23-200603:26 PM

[Dennis_Knutson]

I suspect that the new XControl in LabVIEW 8 could do what you want and make it behave like the VISA Resource name Control. Someone who actually has the latest version can confirm or deny that. Lacking LabVIEW 8, you can create a subVI that passes the strings back to the main and use a property node in the main. Or, create a subVI in which you pass a reference to the control in the main and then a a property node in the subVI can write to the reference. Just having a property node in the subVI doesn't work because it would be referencing the control in the subVI.

[altenbach]

---

@Kenneth.Miller wrote:
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. 

---

I don't think it is a great idea to have the end user operate the toolbar buttons and have VIs sitting there in edit mode. Once an application is ready to be deployed to users, it should be set to run when opened and have the tool bar hidden. Now your initialization code will be run after the users opens the VI, then the VI could wait for further input, e.g. an activity of a START button sitting on your front panel to execute the rest of the code.

[Kenneth.Miller]

Well I'm attempting to create a toolkit of sorts for our company internally. And duplicating the function of the VISA RESOURCE NAME control is exactly the behaviour i'm looking for.

Regards,
Ken

[Darren]

In this case, Dennis' suggestion from earlier is about the only way you can do this...you would need to write an XControl, which requires LabVIEW 8.0 or later.

-D

[Kenneth.Miller]

Thanks,

    Actually we've reverted to 7.1 because we've run into many problems trying to get 8 running. So this bit will have to wait until we switch to 8. Thanks everyone.

[smercurio_fc]

I would tend to agree that the XControl is probably your best bet. However, since you reverted to 7.1 you could try something like the following clumsy approach:

[Dynamik]

Hi Ken,

I worked-up this example before realizing Smercurio already proposed it!  Still, it's a slightly different approach and may be of some use.

Cheers.

[Jarrod_S.]

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.