Add support for using the property node in LVOOP

[tst]

The property node has two major advantage over LVOOP - it allows placing a lot of function calls in a horizontally limited space and it uses text, which is MUCH clearer than small icons (IMO) for something like this. It would be nice if LVOOP had support for this as well.

The implementation I'm thinking of is basically having VIs which will be marked as property VIs (similar to what XControls have) and will only be allowed to have a single input (or output) other than the class and error I/O. These will appear in the list when you connect an LVOOP object to a property node (ideally with the properties from the parents as well), somewhat like this:

When you run the code in this image, LV will run the VIs sequentially, passing the object and error I/O from one VI to the next.

I know that NI already tried to do this in the past, but didn't finish it. Hopefully, enough support here will encourage them to pick it up again.

[PJM_Labview]

This is an excellent idea. I love it! This could also be used to show the inheritance (like the LV built in object [ex:Gobject>>Controls>>...]) using a separator when picking up the property from the available list.

Now, thinking about the implementation, I can see how this would be quite involved but I think that this will really make the class more accessible (after all, many LabVIEW developer are used to the native property/methods nodes concept).

Note: We should also probably have the abilitiy to specify whether we want to threat this as a propery or a method.

[tst]

> This could also be used to show the inheritance

Definitely. I mentioned this, but didn't make it prominent enough.

> We should also probably have the abilitiy to specify whether we want to threat this as a propery or a method

Well, the difference (in LabVIEW) between a property and a method is that a property has a single read/write value and a method can have more than one input and an output (can anyone say C++ method?). I'm assuming that properties are intimately linked to the C++ class properties and use some sort of shared framework which saves NI time when needing to add property-specific code.

LVOOP itself doesn't have "properties", of course, so the most you can ask for if you want "methods" is the ability to call LVOOP VIs using the invoke node interface. I actually like this less, mainly because invoke nodes tend to take more space than subVIs for no good reason and will change their size if you change the name of I/O, etc.. If you want, you can change every VI today to have the "express VI" look which gives a top to bottom list of all the VI's I/O.

Of course, I called these "property VIs", but that should not imply a direct connection between the input and a value in the object's data cluster. This is a standard LVOOP VI with the only limitation being that it only has one input (or output). What you do with that input inside the VI is your business.

[TCPlomp]

This is a really good idea!

Ton

PS a method can have 0 in/outputs, for a Database class there could be a cleanup/defrag method.

Ton

[Intaris]

Like properties for XControls, but with inheritance.

Seems like a no-brainer.  No wonder I never thought of it... 😄

[AristosQueue (NI)]

As was said in the original post... we did have this implemented at one point, but it wasn't quite stable, and it got cut from the feature list back in LV 8.2 for lack of time and I've never gone back to complete it. It's syntactic sugar (meaning it doesn't enable you to do anything in the language you couldn't do otherwise), but useful sugar (meaning that it lets you develop VIs faster/cleaner/etc by having this alternate syntax). We have been working on features for LV classes essentially in order of popular demand, and other items keep trumping this. If there's enough kudos, this is definitely something that could be worked on for a future LV version.

[jgcode]

This would be really nice to be used as a constructor - you can set a lot of properties at once - very neatly - on the BD.

Kudos! 

[Daklu]

The only thing I don't like is the specification that the property vis will run sequentially.  I believe the order of the property vi execution should remain undefined.  Linking property vi execution order to the order of the property node inputs violates the common understanding of how property nodes works.

It is easy to create situations where changing the execution order of property vis will change the behavior of the class.  If class property nodes use sequential execution under the hood it allows a class developer to release a class with the caveat, "If you're going to use a property node the inputs have to be in x order."  Executing property vis in an unknown/random order forces the class developer to put more thought into declaring member vis as properties.

Note - Randomizing the execution order doesn't make it harder to create the situation I described above.  What it does is require the class developer to fix the code rather than documenting a workaround.

[tst]

1. Property nodes already execute top-to-bottom today. I'm not sure which "common understanding" you speak of, but this would simply be a logical extension of that behavior and would basically be like stringing the class VIs together (which you need to do due to the by-val nature of LVOOP). BTW, not only do they execute top-to-bottom, but by default, an error in one of the properties prevents the rest of them from executing.

2. If the class developer feels that there is a sequence of operations which needs to be performed as a unit, then they should create a single method for that, with as many inputs and outputs as necessary. No one is forcing the class developer to create a property VI for every single thing in the class (or for anything, for that matter).

[Intaris]

Introducing anything other than top-down sequential execution would be a very bad idea.

There's absolutely no reason for it and would make much of what we I use property nodes for unusable (Setting plot parameters).

Message Edited by Intaris on 08-12-2009 04:27 AM

[Daklu]

---

tst wrote:
1. Property nodes already execute top-to-bottom today. I'm not sure which "common understanding" you speak of, but this would simply be a logical extension of that behavior and would basically be like stringing the class VIs together (which you need to do due to the by-val nature of LVOOP). BTW, not only do they execute top-to-bottom, but by default, an error in one of the properties prevents the rest of them from executing.

---

Really?  I didn't know that.  I haven't seen it in documentation or discussed anywhere.  I've always viewed it as one lump operation that occurs in parallel.  I withdraw my objection.

---

Intaris wrote:

There's absolutely no reason for it and would make much of what we I use property nodes for unusable (Setting plot parameters).

---

How do you have an application that depends on the order of the property node inputs?  I can't visualize how you would set that up.