LabVIEW 8.20

[ad_dekkers]

"GOOP class" is the name for classes from the Endevo toolkit.

"LabVIEW class" is the name for classes native to LV.

I'm only being pedantic about the names so that when I answer the next part of your question we're both clear what I'm referring to. ;-)

A LabVIEW class works completely different from a GOOP class. LabVIEW classes behave like clusters, GOOP classes behave like refnums. There are indeed use cases when you might find that the techniques used for making GOOP classes are useful hand-in-hand with LabVIEW classes. In fact, even though LabVIEW now has native classes, Endevo will be releasing a new version of their toolkit later this year, since the two techniques are complimentary, not competitive.

Because of the functional differences, you cannot convert one type to the other type. Not that there's a requirement to do so... the GOOP classes will continue to function in LabVIEW 8.2, and you may find yourself using both types. The native LabVIEW classes should be more useful to the bulk of customers just because they are consistent with dataflow design. The GOOP classes, with the reference to data model, will be of use in really advanced programs where you're actually modeling system resources (such as writing a device driver).

Thanks for your reply.

I "played" a bit with the labvoop, but i will stay with the endevo stuff!

A remark about Labvoop: Where is the "Cluster palette" menu item in the right click pull down menu?? ?

[Aristos Queue]

Thanks for your reply.

I "played" a bit with the labvoop, but i will stay with the endevo stuff!

For your existing apps, I agree. Stick with the GOOP Toolkit -- refactoring should only be undertaken with a driving need. But for future development, I encourage you to take a deeper look at the native implementation. You'll find a lot of power and performance benefits.

A remark about Labvoop: Where is the "Cluster palette" menu item in the right click pull down menu?? ?

Not an oversight. This is one of those areas where we decided we didn't have enough info to decide what all needed to be in that palette. Sometimes, for example, the unbundle/bundle nodes are useful but not if you popup when not on a member VI since you can't use them. So we just decided to defer on this until we get some user feedback on what would be useful to include.

LabVOOP does not support templates inside of class.. How do I suppose to create 25 methods (say) without wire same code again and again, and not to clip-paste it? e-eh..

What do you mean? You can put .vit and .ctt files inside the class. You can instantiate from those templates. What support are you looking for?

[proximableu]

What do you mean? You can put .vit and .ctt files inside the class. You can instantiate from those templates. What support are you looking for?

I can put .vit in a class, but when I try to make "new from template" the new vi vill be broken, and then, if I will try to open .vit, it will be uneditable and broken with message "This vi has been editet in another application instance". But, if I remove .vit, new vi that I made from template will be not broken anymore. Readding Template will make the same thing again when I try to make one more vi from it.