Scripting - Change server class for control of type LVObjectRefNum

[matt.baker]

How can I change the VI Server Class of a LVObjectRefNum control using scripting (i.e. like the following recording):

Do this using scripting?

Why I want to do this:

I want to get a list of supported properties for each VI Server Class type programatically. Many types have some sort of  Label property, but there is no common ancestor that can be used. This would allow me to read the Label.Text value for all supported types. For eaxmple all of the following inherit from GObject directly, but only a selection have label properties.

Label property present:

Pane

Splitter

Constant

Label property not present:

Decoration

Tunnel

I am hoping there is a list of avaialble VI Server Class types that I can easily index through to cover every type.

[wiebe@CARYA · Accepted solution]

I used a class constant, which made it easier to set. You then have a ClassSpecifierConstant, that has a SetType method. If you set AllowAltName to true, it accepts class names. Note that the class specifier constant does not need a value to get the properties.

I don't see how to do this on controls. If you insist on using a control, I'd convert the control to constant, then set the type, and convert back. Or instead of converting, create an indicator\control from the constant if that's easier.

Just went through this process for the same reasons. Next step would be to call Get Property by the ID, so you'll need a table of property names vs. property ID's.

Very cool stuff. Since the results will need to be variants, I automatically handle arrays in my code. That allows me to call Get Label on a reference, or an array of references. So I can call Controls[], and wire the output to Get Label (using the same VI, specifying the property with a string).

My ultimate goal is to add methods, so I can do advanced search and replace queries. Methods are a bit more difficult though...

[wiebe@CARYA]

Something like this. Apparently, changing the constant to control returns an error. So as often with scripting, we need a workaround...

Obviously, all connections to the original control (connector pane, wiring, etc.) need to be restored.

An of course this code would be a lot easier if we had the API we're trying to make. I'm now actually at a point where the code I'm using to script my code can use my scripted code.

Lots of fun .

[wiebe@CARYA]

Just for completeness, I prefer it like this:

A Property Node wired to it will stay wired, so it's easy to get all supported properties that way.

[andres.vargas]

This is also being discussed here and it might be helpful to you as well.

[wiebe@CARYA]

ShaunR's method is pretty neat (learned something new), but for our purposes it won't be too useful I think. It needs a type, and the only way it will get one is by hardcoding it (or scripting).

I don't think there is a way we can produce reference types dynamically (e.g. by class name)?

[matt.baker]

That's extremely helpful. Thanks very much for this!

I don't require it to be a control so that works perfectly.

I'll have a proper read through now, but glad I have something that works.