How to get a LabVIEW class object to expose an invoke-node method?

[tbd]

Hi,

      I like the property/invoke-node "paradigm" used for interacting with "objects".  Can LabVIEW-class objects expose their properties and methods this way?  Can one or more LabVIEW-class objects be compiled into a library or "assembly" (or other distrubution format) that allows the property/invoke-node usage?

I've looked at (but not completely understood) "Creating LabVIEW Classes".  Have also searched for related posts.

The pic below shows an invoke node wired to a class with a Public VI "VAT.Status.Hello.vi".  I'd like to see VAT.Status.Hello show-up as a Method.  (I just tried "Select Method", and selected "VAT.Status.Hello.vi" but dialog's "OK" button stays greyed-out.)

Cheers.

Message Edited by tbd on 03-29-2007 03:15 PM

[Steven_C]

Hi TBD,

Thank you for your post! I will look into this question and post back what I find out about this. Have a great day!

Best regards,

Steven

[tbd]

Hello Steven,

      Compliments to the folks who did the LabVIEW 2 page!

Cheers!

Message Edited by tbd on 04-01-2007 10:33 PM

[AristosQueue (NI)]

Hello. This is your friendly neighborhood R&D guy for LabVIEW classes.

Regarding your request about property and invoke nodes as relates to LV classes....

Short story: We would like, someday, to support the property node. We have no intention of ever supporting the invoke node.

Long story: As we were creating LV classes, we had to evaluate the right programming interface for these things. We wanted LV classes to behave as new data types in LV. A developer should be able to create a LV class, then give it to someone who doesn't even know OO programming, and that second programmer could use the new data type without learning a lot of new concepts. From this principle, we held fast to the idea that the programming interface should be subVI calls whereever possible. The invoke node is really nothing more than a VI minus the icon. If you want, you can popup on any subvi node and uncheck the option "View as Icon". This will make the node display in a way that has the terminals listed as text, like the invoke node. So, at the end of the day, the invoke node is simply a subroutine call in LV that is language dependent, as opposed to the language independent iconography of LV generally.

The property node is a slightly different story -- the functionality of a property node is actually different than an invoke node as its terminals are various subsets of the properties available, not a fixed list of parameters like the invoke node. The property node provides a nice interface for setting multiple properties in a block and only having to check a single error return. Very friendly. Our intent is to allow you to create a VI that has 5 terminals: object in, object out, error in, error out, and either a single input or a single output of your chosen type. VIs with this conpane could be marked as "properties" of the class and would show up when you wire the class wire to the property node. We would call the subVIs behind the scenes as needed to get/set the properties.

This is on the longer term roadmap because it is "syntactic sugar" -- it sweetens the programming style, but it is not necessary to program effectively. You can get the same effect by writing those same VIs and stringing them along on a block diagram "railroad track" style. We'll probably get around to it in three or four versions of LV -- there are some major user requests that impact functionality that have to get done first.

PS -- in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future of people thinking there's a way to use these nodes.

Message Edited by Aristos Queue on 04-02-2007 09:56 AM

[Tomi_Maila]

AQ, what is your estimate of this "long term" roadmap?

I don't really care that much if the visual outlook of methods are similar to that of invoke nodes. However I'd really much like to use the right-click shortcut to create class methods. So if I'd right click on a wire or a terminal of type MyClass, I could select any of MyClass methods from an appearing menu. I think this should be feasible to implement quite easily.

Tomi

[AristosQueue (NI)]

That feature is already available.

Assume that all your class' VIs are saved in a single directory. Use the menu editor to create a .mnu file that is sync'd to that directory.
Add that .mnu file to your class and set it as the default palette for your class.
Now when you right click on your class wire or terminals, you'll have a source palette for your class' VIs.

Next you're going to ask "what about parent class" -- sorry, can't help you there at this time.  Having something that automatically syncs up your class' VIs no matter where they are on disk, and keeps track of parent class, is a nice idea. We've tried it twice and been unhappy with the results. Keeping it up-to-date while it is being edited is hard -- especially when the biggest complaint is that items keep moving in the palette. It isn't something that I'm involved with directly.

I encourage everyone to use the project tree as a palette. It works pretty well -- a listing of your classes and the VIs that is open. You can drag directly from the tree to a block diagram to drop functions. In the absence of a updating palette, this is what I've been using. Seems to work well.

Message Edited by Aristos Queue on 04-02-2007 10:34 AM

[Tomi_Maila]

---

That feature is already available.

---

I was rather maning something that is automatic and doesn't require anything from the user except selecting one of the methods that is available for particular class including the ancestor methods that are in the scope of the VI being edited. I hope you'll succeed when you try it the next time.

Tomi

[tbd]

Hi Aristos,

      Thanks for the reply!  It was a bit dissappointing, though.

It appears the LabVIEW-class object will be moving away from (what seems to me) a convenient object-interface presented by the invoke-node/method paradigm - which allows us to interface with a large set of "objects" (.NET, ActiveX, LabVIEW GUI, VISA Resource, ?) in a similar manner and independent of the object's origin.  Being able to read the methods and parameters that appear in these nodes is also helpful for understanding diagram logic!

I do like the option of dropping a friendly "VI looking" icon on the diagram, but perhaps an optional - even default - VI-icon representation for a class-object invoke-node is feasible - so the LabVIEW class-object could be the more generic object first, but with a traditional-G representation(?)

Given the answer "We would like, someday, to support the property node"

and "in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future",

... I guess you'll break the wire in the next version, but (perhaps) allow it again - if support of the property node is ever implemented?

Regards.

P.S. For the record, huge THANKS to whoever it was that straightened-out enumerated-types (somewhere) between LV4.1 and LV6.1.  Every time I add or remove an enumeration in a typedef, I silently give thanks to the bright and thoughtful soul(s) who made this valuable tool work so well!

Hello. This is your friendly neighborhood R&D guy for LabVIEW classes.

Regarding your request about property and invoke nodes as relates to LV classes....

Short story: We would like, someday, to support the property node. We have no intention of ever supporting the invoke node.

Long story: As we were creating LV classes, we had to evaluate the right programming interface for these things. We wanted LV classes to behave as new data types in LV. A developer should be able to create a LV class, then give it to someone who doesn't even know OO programming, and that second programmer could use the new data type without learning a lot of new concepts. From this principle, we held fast to the idea that the programming interface should be subVI calls whereever possible. The invoke node is really nothing more than a VI minus the icon. If you want, you can popup on any subvi node and uncheck the option "View as Icon". This will make the node display in a way that has the terminals listed as text, like the invoke node. So, at the end of the day, the invoke node is simply a subroutine call in LV that is language dependent, as opposed to the language independent iconography of LV generally.

The property node is a slightly different story -- the functionality of a property node is actually different than an invoke node as its terminals are various subsets of the properties available, not a fixed list of parameters like the invoke node. The property node provides a nice interface for setting multiple properties in a block and only having to check a single error return. Very friendly. Our intent is to allow you to create a VI that has 5 terminals: object in, object out, error in, error out, and either a single input or a single output of your chosen type. VIs with this conpane could be marked as "properties" of the class and would show up when you wire the class wire to the property node. We would call the subVIs behind the scenes as needed to get/set the properties.

This is on the longer term roadmap because it is "syntactic sugar" -- it sweetens the programming style, but it is not necessary to program effectively. You can get the same effect by writing those same VIs and stringing them along on a block diagram "railroad track" style. We'll probably get around to it in three or four versions of LV -- there are some major user requests that impact functionality that have to get done first.

PS -- in the next version of LV, wiring the LV class to the property/invoke nodes will break the wire so we'll avoid confusion in the future of people thinking there's a way to use these nodes.

Message Edited by Aristos Queue on 04-02-2007 09:56 AM

Message Edited by tbd on 04-03-2007 12:39 PM

[AristosQueue (NI)]

> I guess you'll break the wire in the next version, but (perhaps)
> allow it again - if support of the property node is ever implemented?

That is the plan, yes. 🙂