LabVOOP Showstopper

[jdunham]

Zoinks! I was just refactoring an application and converting some typedef clusters to lvclasses, now that I am getting more accustomed to LabVOOP. At the same time I was reading a stale info-labview post by Stephen Mercer (actually posted by Matthew Brooks on 5OCT2007) about how great LabVIEW is

QUOTE

It's the single most unit testable language that I know of since every individual

function is indepenently runnable.

It hit me like a thunderbolt. The price I would pay for making all of my cluster typedefs into lvclasses is losing this feature; the ability to test any VI by typing in the values and pressing the Run button (or using Suspend When Called and making a few changes). However, you can't enter data into an lvclass object on a panel, because it's just an icon, instead of a cluster. How do you test your class's methods without writing twice as many VIs?

Even within a class, I can't open up the private data cluster (the .ctl file), copy its contents and paste them into any other icon of that lvclass. I can probe the wire and see its contents, but similarly, I can't copy from the probe into an lvclass control, even in the same VI. Even if the probe copy worked, it would not be sufficient, because I need to be able to modify the data easily.

I have to make a new private method to populate the class with test data and copy/paste from that or write a test wrapper.

The copy/paste problem is grave enough but it's still a poor substitution for direct data entry.

At this point, I just can't see converting my large application to LabVOOP without a fix for this. The other developers on the project will have my head on a plate if I take away the ability to test the subvis, and to use Suspend When Called to view and modify the data during runtime. With traditional typedefs and enforcing encapsulation on your own, you get almost all of the benefits of LabVOOP, and you can still leverage the power of LabVIEW (in other words, you can get your work done).

This is my suggestion:

If a VI is owned by a class, then its front panel should allow you to see and use the private data cluster instead of the object icon.

Extending this idea a bit, one should be able to make a reasonable user interface out of an lvclass method VI which should behave like a traditional (non-LabVOOP) VI with a strict type def cluster. It could be a right-click option whether the cluster is to be displayed if the lvclass is locked.

If the class is used in a public scope (or as member data of another class), then the icon should be shown like it is now, and the user should only be able to copy and paste the data. In that case there ought to be an easy way to open up a new VI, add it to the class, and paste the contents of the clipboard so that the value can be seen, modified, and pasted back to the public VI.

It would be even cooler if you could crack open an unlocked class's icon and modify the data when necessary, but that sounds hard, whereas the other suggestions should be pretty easy to add to LabVIEW.

I still plan to use some LabVOOP for some by-reference objects, like the Singleton design pattern, since those are hard to debug on front panels and I'm pretty comfortable with the queue and notifier functions. But I think this makes lvclasses unusable for by-value objects which are otherwise a great idea.

[Justin Goeres]

I've been meaning to write a post about this exact issue for a while, but hadn't gotten around to it. Thanks for bringing it up. :thumbup:

I, too, see this as a huge problem for classes. It hasn't stopped me from using them because they're so great in so many other ways . But I'd go so far as to say that I probably test my LVOOP code less than my non-LVOOP code, or at least I test it in larger chunks, because the effort required to actually do the tests is greater.

I have wondered, though, how LVOOP fits in with the idea of automated unit testing. Maybe the impact of not being able to set class data element values directly on the front panel is less in that context?