Please add invoke nodes for objects so I can use them for methods like property nodes together with DVR. Didn't found this topic, maybe it's duplicate....
Can you clarify your idea a bit more please? What objects are you referring to? What methods and property nodes are you looking for that aren't currently in LabVIEW?
There was a discussion about this during the 2010 beta period. Since the discussion was not public, I'll post a few of the responses.
My original response to the idea:
We chose to only make property nodes available for classes because it vastly reduces wiring and horizontal space Using an invoke node syntax would greatly increase the space used on the block diagram.
Aristos Queue wrote:
There are three arguments against invoke nodes and two in favor of invoke nodes. Of the two favorable, one of them can be solved better with other options and the other, well, it might actually be an argument, but its positives do not (IMHO) outweigh the negatives.
Against #1: Invoke nodes would make classes look foreign. The goal has been to make classes look and behave like basic LabVIEW data types. Today, someone who writes a class can give it to someone who uses a class. The user of the class may have no idea what a class is or how it works. To them, it looks like a fancy wire, but it carries data just like any other wire in LV and it has subVIs that do operations. That gives them knowledge of how to work with this never-before-seen data type. Anything with invoke and property nodes is generally a closed box, designed by someone back at NI. Worse, things that use property and invoke nodes are all -- without exception today -- reference based. Classes don't work by reference. They behave like dataflow. When we first shipped classes in LV 8.2, I was sorry that the property node syntax didn't make it in. In retrospect, I am glad it didn't. Not using the property nodes helped a lot with education about what a class was and how it worked, and my sense is that the confusion would have been worse if lots of classes were running around using the property node syntax. We're now adding property nodes because property nodes help with some syntactic issues. I hope that they do not increase the by ref/by value confusion. In fact, I'd like to see a community consensus around the idea that perhaps (just perhaps) the property node syntax should be reserved for classes that are exposed entirely as data value references, specifically to avoid the by value/by ref confusion. Maybe it'll be ok, and its that maybe that has me going along with this project in the first place. But I believe Invoke nodes go too far in changing the readability of the diagram. When and if someone convinces me that the Add primitive needs to be replaced with an Invoke Node that does addition, that's the day I'll agree that class methods should be invoke nodes.
Against #2:What is an invoke node? It is a method call. What do methods look like in LabVIEW? They look like subVIs. I believe having two different nodes that are exactly the same thing but look completely different is a problem. Try reading a block diagram where all the subVIs have the same icon. Not easy to figure out what is going on. The problem is similar when you have two nodes that actually are the same subVI but look completely different. In fact, it's a hole in the current implementation of the property nodes that we are likely to fix in the 2011 release. With the 2010 release, dragging from the project tree and dropping the subVI from windows will drop a subVI node. The plan is to fix this in 2011 so that these alternate methods of dropping the subVI will -- if the subVI is part of a property -- drop a property node instead, thus closing that visual gap.
Against #3: Unlike the property node, an invoke node does not add anything syntactically to the method call. Arguably it removes something important: the icon of the method is lost in an invoke node syntax, which moves LV toward a text-based, human-language specific syntax. They're also big. Mostly I hear screams about anything that takes up more diagram space. If you happen to like big, pop up on the subVI node and turn off "View As Icon". You now have a yellow block with text for the name of the method and giant left/right terminals for wiring. The invoke node adds nothing to this. The property node, with its cascade syntax, can actually save space when you're accessing multiple properties and it helps keep pairs of read and write VIs accessed through a common interface. There's more syntactic relationship between a read and write property node than between the glasses glyph and the pencil glyph of the read and write subVI.
For #1: They're nice in the editor for quickly changing methods. That's something that can be easily addressed with auto-built palettes. We killed auto-built palettes back in LV 8.2 because of user feedback, but I hear tell that the user community has built them back as part of the JKI popup framework, to rave reviews. That surprised me, given the reception they got originally. The auto-built palettes solve the access to methods problem, without causing the problems of the invoke node.
For #2: If you have property nodes then you should have invoke nodes. The symmetry argument is one that I can't really argue against. The existing types have created an expectation that if a wire connects to a property node then it also connects to an invoke node. Classes will violate that convention. Which isn't good... and that is why I'm now supporting deprecating invoke nodes for all wire types. If having methods that are 32x32 is good enough for Boolean and path then it should be good enough for VI Refnum. (To some degree, I'm serious... I actually had this discussion with senior architects of LV about 10 years ago when I first joined the LV team. The resources to do such a refactoring would be sizable, though, and hard to justify given some of the other projects we'd like to work on instead.)
I don't think that we really need invoke nodes for LVClasses. But the one feature I am really missing is Dynamic Dispatching of Class DVRs.
We know that this is possible, because it's already implemented in property nodes. I really like this feature and we are using it frequently in our company.
So what do we do if we need a dynamic dispatch method for a byref class?
We circumvent the issue by using several property VIs - similar to the way you have to do it when working with certain graph properties (eg. set "Active Plot" and then work with this plot's properties).
From my point of view this leaves us in a situation, where we won't get property nodes because of the reasons mentioned above and we won't get dynamic dispatch VIs for DVRs, because they wouldn't be well-defined.
The last issue could be addressed by inventing some kind of method structure in a class that defines methods to be called by reference. But we won't get this, because NI doesn't like the idea of methods...
> We know that this is possible, because it's already implemented in
> property nodes. I really like this feature and we are using it frequently in our company.
And that is, quite simply, A Very Bad Thing for all the reasons cited in my post that you already linked to. Luckily, properties tend to be limited in what they can do, so you are likely to go a long time before it burns you.
> The last issue could be addressed by inventing some kind of method structure
> in a class that defines methods to be called by reference. But we won't get this,
> because NI doesn't like the idea of methods...
You already have this ability: write a VI that takes the DVR as input. You then have a method that is designed to be called by reference. You do not need a new method structure to get that functionality.
I always found it annoying that I couldn't drop an invoke node on the BD, wire an object to it, then pick a method. I finally found a solution: I created an XNode (yeah, I know I'm not supposed to do that) which I placed on the "Cluster, Class, & Variant" palette. I drop it on a BD, wire it to either an object, or a DVR to an object, then when I click on it with the Operate tool, it shows a menu of methods available for the object. Selecting one replaces the XNode with the selected method VI.
I would be happy to share it, but there's no way to attach a file here.
"If you weren't supposed to push it, it wouldn't be a button."
