Create reference in a new vi if scripting is enabled

[tshurtz]

Often times I need to change a property of something in labview that seems to only be available through a property node. And often I don't want to do it during run time just once at development but I find it really hard to get references to some objects and I want them in another VI that I can run real quick to set the property and then be done. If you have the option enables that shows labview scripting property node options and invoke nodes, can under create there be a  Create reference in a new vi. And if you click it you get a new VI with just a ref that you can then do whatever you need with it. And please make this work for anything that has a property or method related to it. I have some tools that I wrote that can kind of do this but I am sure it is not a good way of doing it (but it is the best I have got).

[AristosQueue (NI)]

Even though lots of users have the Tools>>Options setting enabled because they sometimes need it, scripting is pretty rarely needed overall. I don't think polluting most new VIs with a node that most people just have to delete immediately is the wrong solution.

The palettes already include a node that gives you a reference for the current VI. Search the palettes for "This VI".

Does dropping that node suffice for your needs?

Do we need to make it easier to find?

Tangent:

"Often times I need to change a property of something in labview that seems to only be available through a property node."

Usually the complaint is that we added something to the UI that we failed to add a scripting call for. What is this mysterious feature where we added to scripting but not to the UI?

[tshurtz]

I think you misunderstood me. I would not have the reference in all vis. only ones specifically created to get a reference to a different vi. 

As I mentioned I do use some strange ways of getting references to objects in other VIs that work but are clumsy at best. It is usually something like create a static ref to the VI that has the item I want to manipulate then I select it and use the selection list property node to get refs for the item. but then I have to convert it to a more specific class to get at the properties or methods I want.

Its ugly but does the job kind of (I would like to automate the bit of converting to the right class a bit better). I have toyed a bit with plugins and may write my own to do it but I am sure it will not be the best way to do it.

[tshurtz]

Sometimes It isn't that they don't exist in the UI but that they are not easily accessible.Say for instance I want to populate dozens of strings/values pairs into a ring control (I just did this today). I have them in a spreadsheet and with a quick loop I can get them all in there but entering them through the UI would take me hours to make sure I get them all right.

Another instance of this is to set data entry limits on an numeric indicator. We use this "meta-data" that exists for the indicators to make or coding cleaner and they are in there via property node but to get to them through the UI you have to turn them into a control, change the values and then change back to indicator. This would arguably be quicker through a property node if I could instantly get a ref in another VI that I could run real quick.

Another is precise control on the location of the front panel origin of a vi. I can use the scroll bars to get close but I have not found a way to set it to a precise pixel location. I can do it via a property node in seconds but getting the ref in another window is the most time consuming part of it.

One that I have never found the UI for was setting a control/indicator to blinking. That one isn't too bad to just set at the beginning of the VI if I want but why set it every time its run if it is really just something I want set at development time. 

I have come across many dozens of other instances where finding the UI or interacting through it was less than efficient. I suppose you could spend time improving all of those UI elements, but just getting a ref in another VI would make me happy and should only be one development task. I guess that might just be me and if so I will work on improving my own plugin idea.

[tshurtz]

Here is the example of the ring thing I did (the item labels and values have been changed to protect the innocent. Again I felt this was still more efficient even with having to get the ref in a roundabout way but would have been much more efficient than through the UI if I could get it instantly. (the small vi in the loop just converts sting to int pay no attention)

[AristosQueue (NI)]

Can you post a quick picture of the kind of diagram you'd like to see, just so I know we're on the same page?

[tshurtz]

then in a new vi 

After that I do whatever I want, say change the properties of dozens of plots on the graph with a for loop etc.

[tshurtz]

Again this would only show up if scripting was already enabled in options

[tshurtz]

Another place I was just reminded that I would very much use this is for .ctl items. You can't even typically create property nodes for them as there is no block diagram. 

[AristosQueue (NI)]

Oh. I see what you're trying to do.

Yeah, that's not going to happen, at least not the way you propose. I thought we were talking about VI references, not references to parts of a VI. References to parts of a VI cannot be static links without us adding a whole lot of reference lifetime tracking, which would a) be a lot of work for very little return on investment and b) probably introduce performance hit to scripting, and scripting has enough performance problems. So just creating a static reference I am pretty sure is off the table.

But what could be possible is to script code to get the given object. We could drop a static VI reference to the target VI and then script a lookup of the target object. The UID is a fixed integer assigned to each object as it is created... there's a scripting property you can use to read any object's UID.  I don't think we have an existing way to directly look objects up by UID, but we could introduce a way... something like:

[Note: Shortly after finishing creating this image, one of my co-workers says that FPGA ships a VI to do the UID lookup, but it isn't part of Core.]

[AristosQueue (NI)]

And a few minutes after THAT, another co-worker says that such a VI is installed with Core: vi.lib\VIServer\UID to GObject Reference.vi

So... guess what? That means all the parts are there if you want to create your own right-click menu item for this functionality and share it with the community at https://ni.com/lvmenus. Definitely not the answer you're looking for, right? 🙂 But it may be a faster way to get this functionality than waiting for prioritization from LV R&D.