LabVIEW Shortcut Menu Plug-Ins

cancel
Showing results for 
Search instead for 
Did you mean: 

looking for "open typedef" menu item when clicking on typedef wire

I'm looking for a plugin that would have a menu item that's available when right-clicking on a typedef wire. It would have the option to open the typedef for editing.

Is anything like that available?

Comments
Darren
Proven Zealot
Proven Zealot
on

I haven't seen a plugin that does this, but it sounds useful, and not difficult to implement. If you'd like to take a stab at it, check out the instructions for writing and posting plugins here.

Hooovahh
Proven Zealot Proven Zealot
Proven Zealot
on

Not that I know of, but it is definitelly possible and the community would love it if you made one to share.  A quick tests shows that if you have the wire reference, you can use the private method of Value on a wire, and that value contains the type which includes the path.  You can then use the Get Type Definition Path function from the vi.lib (and on the palettes starting in 2015) to get the path.  Not sure why the value method is private, maybe it is incompleted for some edge cases.

Darren
Proven Zealot
Proven Zealot
on

I've never used the 'Value' property of the Wire class, I don't trust it. A safer approach would be to get the Terms[] property of the wire, and then get the Data Type of the first terminal in the array (always the source terminal).

AristosQueue (NI)
NI Employee (retired)
on

Yeah... trusting the Wire:Value property is a bad idea. It gets weird on broken VIs, and if you're right clicking on wires, you might right click on a broken VI. And I'm not sure, but I'm pretty sure it can crash on an unbroken VI that hasn't been compiled (becaues it tries to dig into the old dataspace and interprets whatever data it finds there as the wire's new data type, with whatever results that implies).

That property was only ever meant to be used only on running VIs, and even then, there are caveats. Overall, just a bad property to use. It's private for a reason. Stay clear.

Hooovahh
Proven Zealot Proven Zealot
Proven Zealot
on

Thanks for the heads up AQ, the terminals approach is definitely a better one.

vishots.com
Member
Member
on

Ok, I had an 11hr plane ride and decided to give a stab at it.

Here's what I got. But notice the problem I have. The typedef opens in the wrong context. How do I fix this?

Screen Shot 2016-09-22 at 10.25.49 PM.png

Darren
Proven Zealot
Proven Zealot
on

Get the owning app of the user VI (i.e. the one that was right-clicked on), and use that to open the reference to the typedef. Make sure to close the VI and App references when you're done:

Untitled.png

vishots.com
Member
Member
on

Thanks, that solved it.

vishots.com
Member
Member
on

Stuck on another problem. When the wire connects to a constant, how do I cast down from terminal to constant?

I tried casting the wire terminal to various constant data types but it didn't like that.

Darren
Proven Zealot
Proven Zealot
on

You could try getting the owner of the terminal and see if it's a constant.

But now that I think about it some more, why not just get the typedef path directly from the terminal data type?

ty.png

vishots.com
Member
Member
on

The owner property is what I was looking for. That worked.

Darren, I tried your other proposal, but the path returned was empty. The VI returned error 1004 "The VI is not in memory."

Darren
Proven Zealot
Proven Zealot
on

Weird, it works fine for me. With a diagram like this (the constant, control, and indicator are typedefs, and the subVI has a typedef terminal on its conpane):

1.png

, The following code gives back all the typedef paths:

2.png

vishots.com
Member
Member
on

See my edited comment: The VI returned error 1004 "The VI is not in memory."

Darren
Proven Zealot
Proven Zealot
on

Ah, it's probably a cross-context issue. LabVIEW keeps a cache of variant type information. Get Type Definition Path VI attempts to read the typedef info from the cache. If the info can't be found in the cache, it tries to open a reference to the typedef to read its path. But it only does that in the context that is running the Get Type Definition Path VI. Since you're doing cross-context stuff, that's probably why it's erroring out. So yeah, if your wire is sourced by a constant or a control terminal, your approach would work. But if your wire is sourced by a subVI terminal, you'd have to go a step deeper and get the indicator reference on the subVI panel and get the typedef info from its terminal. And if your wire is sourced by a primitive output, a tunnel output, etc., there really is no easy way... 😕

I should add an Application Reference input to Get Type Definition Path so you can optionally supply a reference to the app instance from which your data type originated. I'll look into doing that for LabVIEW 2017.

Darren
Proven Zealot
Proven Zealot
on

Here, see if this approach works for the 'Data Type' property of any terminal, regardless of source. This is along the lines of the internal change I'm thinking about making to Get Type Definition Path VI:

Untitled.png

vishots.com
Member
Member
on

That works. It simplifies the implementation a lot. The other approach forced me to go down a rabbit hole that was not fun.

vishots.com
Member
Member
on

So I'm done with my initial implementation and wanted to get some feedback from the community. Of course I just couldn't leave it to my initial request, so I added one or two more features into this plugin.

Here is what I got. Please give feedback on menu text wording\position and functionality.

One thing I forgot to show in the video is that when a normal wire is selected, all the items are still visible in the menu, but they are disabled.

Darren
Proven Zealot
Proven Zealot
on

Looks cool to me, I like the menu item names and positions in the list. Nice plugin!

vishots.com
Member
Member
on

One question I have is for the class definition actions. I'm using:

resource\Framework\Providers\LVClassLibrary\CLSUIP_GetAllClassesInThisClassesAppByName.vi

I use that and try to match the class filename from that array with the Data Type class filename.

There seems to be a bit of a delay caused by the time it takes to complete executing that VI. Is there a faster way?

Screen Shot 2016-09-23 at 9.48.07 PM.png

Darren
Proven Zealot
Proven Zealot
on

Yeah, there's a comment in that VI's diagram that indicates that it is slow...that VI uses the AllLibsInAppInstance property to get the names of all the libraries, then it uses the Get Ref By Qualified Name method to create a library method...apparently this approach is really slow.

One suggestion I have is to figure out which target in the project owns the app reference, then use Get All Descendents with a 'Type' input of 'LVClass' (or maybe it's 'LVClassLibrary'? Something like that) to get the classes in your target, then read their Path properties to find the match. I think that approach will execute more quickly than using the CLSUIP VI.

Contributors