LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
tst

Add option to open LVOOP accessor VI from the property node

Status: Completed

Available in LabVIEW 2013 and later. Right-click a class property and choose the 'Open Accessor VI' menu option.

LabVIEW allows us to create VIs in classes and call those VIs by using property nodes. This is very convenient for writing the code, but when running and debugging, there's no way of directly accessing the VI.

 

To resolve this, LV should have an option of opening that VI, for instance by right clicking the property:

 

Open_Acc.PNG

 

This should probably also work when the VI is running and should probably open the dynamic dispatch selection dialog if the VI is a dynamic dispatch VI.

 

 


___________________
Try to take over the world!
10 Comments
asbo
Member

Rather than "Open VI", how about menu options for "Open Read/Get VI" and "Open Write/Set VI" so that you don't have to modify your property node in order to see both accessors.

AristosQueue (NI)
NI Employee (retired)

> Rather than "Open VI", how about menu options for "Open Read/Get VI"

> and "Open Write/Set VI" so that you don't have to modify your property

> node in order to see both accessors.

 

Would you add a popup menu item to a subVI node to open a different VI's panel? To me that would be odd.

Mr.Mike
NI Employee (retired)

@asbo: I like the idea

 

@AQ: A SubVI rarely is part of a pair.  A property accessor typically is part of a pair.  To me there property item is a connection to a property, not the VIs themselves.  I want to access something on property X, now do I want the read or the write?  If I want the pepper, I know it's usually right by the salt.

-- Mike
AristosQueue (NI)
NI Employee (retired)

@Mr. Mike: I kind of buy that, but why would I go to a particular property node to get info about the inverse property? I could buy an argument that in the menu for the Read VI's panel or diagram, there should be a menu item to open the Write VI's panel/diagram. But on a given node, it just struck me as noise to have the ability to open a VI that the node won't invoke. It makes no more sense to me to have a shortcut to get to the Write VI as to have a short cut to open any of the other properties of the object. If I have the Size property showing, why can't I use the property node to go straight to the Color property implementation? To take asbo's comment and apply it here, why should I have to change my property node to the Color property just to get to its implementation?

 

I'm not trying to be hard to live with... I am trying to keep pop up menus as short as possible. They lose value when they get long or when items are pushed into pull-right menus. And every individual item is a strike against.

asbo
Member

@AQ: I agree it's important to keep menu concise and off that slippery slope. I understand your analogy, but I think the Size :: Color comparison is not quite apples to apples because it deals with a completely separate property altogether. I don't expect to be able to convince you and I'm certain you've done more OOP development than I, so I might just be speaking out of inexperience here. Either way, there's no ideal place to jump to the opposite accessor from the VI window, so the thought was that they could have a common, quick source. In all likeliness, it wouldn't be too much toil to pull down the property node, change the property and access type, and then use the simple context menu.

Kiesch
Member

As an additional feature to this it would be great to have a checkbox that enables / disables accessing Property setters and getters during single step execution.

Mr.Mike
NI Employee (retired)

@Kiesch wrote:

As an additional feature to this it would be great to have a checkbox that enables / disables accessing Property setters and getters during single step execution.

 


I'm not entirely sure I understand what you're asking for.  Do you mean that when this checkbox is checked stepping over the property node would actually step into the accessor?  I think it would be better as a separate idea -- i.e. you could step into or step over properties in a property node.  That doesn't require any new UI work and it fits in the existing debugging paradigm well.

-- Mike
Kiesch
Member

[quote]I'm not entirely sure I understand what you're asking for.  Do you mean that when this checkbox is checked stepping over the property node would actually step into the accessor?  I think it would be better as a separate idea -- i.e. you could step into or step over properties in a property node.  That doesn't require any new UI work and it fits in the existing debugging paradigm well.[/quote]

 

Ah right atm step into and step over are both treated as step over. This just would need to be changed to a step into property behaviour (I didn't think of that ^^). That of course would be a better solution than a checkbox.

And I thought this would fit here, since probably 95% of the work that has to be done to implement this feature is the same as with the proposed "Jump to function from property node", since this is essentially what you would do during debugging with single step execution.

User002
Not applicable

I think this one is complete. Works for me in 2016, anyway. Great idea!

Darren
Proven Zealot
Status changed to: Completed

Available in LabVIEW 2013 and later. Right-click a class property and choose the 'Open Accessor VI' menu option.