Property indicating whether a control is on the connector pane

[jandrengen]

When developing LabVIEW automation tools, I miss a way to list the controls connected to a VI's connector pane. That would make it possible for the user to better select which controls to set before calling a VI (dynamic VI call).

An "IsOnConnector" property on a control reference would be very useful. Or better; a property returning an enum with one of the four values: "NotConnected", "Optional", "Recommended" and "Required".

Another solution could be a property like the Controls property on a Panel reference, but only listing the controls on the connector.

[tst]

You can get the reference to the connector pane from the VI's reference and use that reference to get the Controls[] property for the conpane. It also has a WiringRules[] property which returns the rules.

Also, the Control class DOES have an Is On Connector Pane property.

Do you have the scripting API installed?

[jandrengen]

tst,

I cannot see the Is On Connector Pane property on a control reference.

And, no, I haven't installed the Scripting API. I must admit that I didn't know the kit, but in my library, I cannot assume that my customers have it installed. Especially when there's no support or guarantee.

Also, I'm not trying to automate some VI creation and editing, but just some good old dynamic VI calling in LabVIEW and LabVIEW RT.

So the idea is really just a change request, then.

[tst]

First, the scripting API only exposes the properties in the editor. Code which has them will work fine even if it's not installed.

Second, the classes, properties and methods exposed in the API allow not only editing VIs, but also doing what you requested.

I'm not sure what this has to do with dynamic VI calls, since you can pass values to any controls (not just controls which are in the connector pane) and presumably you need to know which controls you want to pass the values to beforehand.

[jandrengen]

Alright. My application is an automation tool for LabVIEW, where the client side (not LabVIEW but .NET) will show the list of opened VIs in the application. The user can then create a test step which makes the server side call a selected VI. When configuring the test step, the user can see the list of controls and indicators of the selected VI. That's how it is today.

Now it would help the user if the list could show which controls and indicators that are actually parameters (connected).

I know this is Idea Exchange, but if you could post a snippet of the Is On Connector Pane property, I would be very happy. I just can't find it...

I don't fully understand what you mean about the code still working if the Scripting API is not installed, because I haven't succeeded downloading it yet. There's an error on the download page, I think. But I will check it out when it's possible.

[Todd S.]

This idea is already implemented in LabVIEW.

[tst]

I don't have access to LV at the moment, but you should have access to the property once you install the API.

The code will work because the API does not ADD anything to LV. It simply exposes classes, properties and methods which already exist, but which have been hidden.

You should note that these properties will not necessarily be available from the ActiveX API which LV exposes (assuming that's what you're using to access the VIs from .NET). If that's the case, you can probably do it by having a VI which will access the data and then call that VI from the .NET code.

[jcarmody]

[jandrengen]

Thanks, tst and jcarmody.

I have installed the scripting API, and I can see it contains all that I need.

It will be interesting to see if I can get it working on LabVIEW Real Time.

I still think that the three properties used in jcarmody's snippet easily could be available without the scripting API installed, because they can be useful for other tasks than scripting VI creation.

So I don't agree with Todd, that it's Completed.

[tst]

> I still think that the three properties used in jcarmody's snippet easily could be available without the scripting API installed

They could, but I think they have correctly been cordoned off. They have little to no relevance for code which does not care about the actual structure of other code (which is basically scripting, which is also about reading existing code, not just creating it).

Anyway, the scripting API has only been offically released with LV 2009, so it's still rather new in its public form. It wouldn't be unreasonable to expect NI it to make it more easily accessible in future versions.

[jandrengen]

The reason I think they should be moved is that I don't think they are about reading code, but about getting information about the interface of the code. When the way to set input parameters before calling a VI dynamically is done by setting the value of the controls, it is important information to know which controls are actually considered the input parameters. And even worse for the output parameters.

Me stubborn? No.

I agree though that this kind of invocation could be called scripting.

I knew that this "idea" / "change request" wouldn't score very many kudos, but that's just because so few will ever need it. Maybe I should find another project...