Jump to content

What's new for LabVOOP in 8.6?


Recommended Posts

The LabVOOP team has a few goodies in the box for LabVIEW 8.6. Nothing major... you can safely assume some yet-unreleased project must've had my team and I distracted. *grin* But let's not talk about vaporware. You want to know the goodies that are ready now...

The LV8.6 upgrade notes may be read in their entirety here. For your convenience, I have extracted out from this document all the features particular to LV Classes. The stuff in [ ] is commentary from me.

  1. In LabVIEW 8.6, all comparison functions (<, >, !=, ==, Sort 1D Array, etc) work with LabVIEW classes. [Details in online help files, but basically, they compare just like clusters do, with some rules for comparing classes of different types. But before anyone asks, :rolleyes: no, you can't supply your own comparison routine.]
  2. LabVIEW 8.6 includes enhancements to LabVIEW class error reporting that might result in fewer unbroken class items listed in the Error List window. [Translation: Breaking one VI in a class now only breaks the callers, not the entire hierarchy and its siblings, and God-only-knows what else. You can all stop sending the protest e-mails now... :worship: ]
  3. The VI Hierarchy window displays LabVIEW classes and dynamic member VIs, XControls, shared libraries, .m files you reference from MathScript Nodes, Express VIs, and static VI references. ["displays LabVIEW classes" means we now show when a VI's only use of a class is using the class as a control/indicator/constant. Showing dynamic member VIs means a caller VI is now shown as a caller of all the override VIs, not just the ancestor implementation. :lightbulb: ]
  4. The LabVIEW Schema palette includes the following changed functions:
    • Flatten To XML—Supports LabVIEW classes and the fixed-point data type.
    • Unflatten From XML—Supports LabVIEW classes and the fixed-point data type. [ :ninja: <<< All the other items had smilies when I finished typing this. I thought this should have a smilie too.]

[*]Report Generation VIs: The Report Generation VIs were rewritten using LabVIEW classes. The report in control and report out indicator changed from reference number data types to LabVIEW class data types. [And, as a result of this, a lot of small issues that result from deploying a class in a toolkit -- such as the wire appearance drawing right in Context Help when hovering over the palettes without loading the entire class into memory -- have been worked out. :thumbup: You may all go forth and develop lots of LabVIEW class toolkits that other developers can inherit from to their heart's content.]

Enjoy!

Link to comment

QUOTE (Aristos Queue @ Aug 1 2008, 11:20 PM)

Report Generation VIs: The Report Generation VIs were rewritten using LabVIEW classes. The report in control and report out indicator changed from reference number data types to LabVIEW class data types. [And, as a result of this, a lot of small issues that result from deploying a class in a toolkit -- such as the wire appearance drawing right in Context Help when hovering over the palettes without loading the entire class into memory -- have been worked out. :thumbup: You may all go forth and develop lots of LabVIEW class toolkits that other developers can inherit from to their heart's content.]Enjoy!

So, we don't have to juggle with different office dynamic VIs?

That would be a truly awesome example!

Ton

Link to comment

QUOTE (Aristos Queue @ Aug 1 2008, 05:20 PM)

I initially thought "great" - an example of a toolkit written with OO in mind, but the first one I opened was this:

http://lavag.org/old_files/monthly_08_2008/post-181-1217693343.jpg' target="_blank">post-181-1217693343.jpg?width=400

Why is there an "HTML refnum" wrapped in a class that refers to a by-reference object repository? Why isn't it all pure LVOOP? I'm not suggesting it should be one way or the other - I'm just wondering about the motivation to this pattern.

PS: nice "unless there is magic" code review comment from Darren :D

Link to comment

QUOTE (crelf @ Aug 2 2008, 11:12 AM)

PS: nice "unless there is magic" code review comment from Darren :D

I don't own Report Generation anymore. The guy who does, however, has the same initials as me, and he sits right next to me... :) Even crazier is the fact that I participated in the code review, but that was his comment, not mine...

Oh, and as for the object repository, that's a holdover from the original design. The user-facing API became class-based, but some of the underlying code stayed the same. Look for the Report Gen codebase to become more OOPish in future releases.

-D

Link to comment

QUOTE (Darren @ Aug 2 2008, 03:22 PM)

...and you're not going to sacrifice his/her name so that we can chatize him/her at NI-Week, are you? :D

QUOTE (Darren @ Aug 2 2008, 03:22 PM)

Oh, and as for the object repository, that's a holdover from the original design. The user-facing API became class-based, but some of the underlying code stayed the same. Look for the Report Gen codebase to become more OOPish in future releases.

OK - great - that makes me happier.

Link to comment

QUOTE (crelf @ Aug 5 2008, 11:43 AM)

That is a really important observation - anyone from NI care to comment?

Yup...if we made it so that when you split the wire you had two different reports, then that would make the toolkit behave differently now than it did in past versions. The last time I checked, LabVIEW users generally like for VIs to function the same after upgrading.

-D

Link to comment

QUOTE (Darren @ Aug 5 2008, 02:32 PM)

Yup...if we made it so that when you split the wire you had two different reports, then that would make the toolkit behave differently now than it did in past versions. The last time I checked, LabVIEW users generally like for VIs to function the same after upgrading.

I know you don't need me to say this, but that's a totally valid answer.

That said, let's talk about the raodmap (if you can): you said "Look for the Report Gen codebase to become more OOPish in future releases", and, based on your other quote above, what benefit does eventually switching from by-ref to by-val have to the report generation toolkit? It would help me understand the partial switch (wrapping the by-ref in the by-val) more if I understood where you're going with it. Is branching a by-val report really a popular-justified use case? If not, what is/are the use case(s)? If you do make it "more OOPish" (great term by the way - I'll be using that in future :) ), then that will definately "...make the toolkit behave differently now than it did in past versions".

As they say in the acting profession: "what's the motivation?"

PS: I appreciate you guys taking time out during NI-Week to keep posting on the fourms. I know how crazy-busy everyone at NI is :thumbup:

Link to comment

QUOTE (Darren @ Aug 5 2008, 09:32 PM)

The last time I checked, LabVIEW users generally like for VIs to function the same after upgrading.

This is surely correct.

And it reminds me of an old problem with the report VIs: Did the changes in LV 8.6 fix the bug that made the report VIs incompatible between computers with and without the Report Gen. Toolkit for MS-Office?

What I'm talking about: The toolkit introduced a new required input to New Report.vi, which meant you were not able to open and run a VI that was built without the toolkit and used LV's regular report functions. If you fixed this immediate problem by wiring a constant to this input, you could run it on your machine, but if you saved this VI, it wasn't possible to run it on a computer without the toolkit any more (sure, you could remove the constant there, but this made it incompatible with computers that had the toolkit installed........). :throwpc:

Has this vicious circle been broken by now?

Link to comment

QUOTE (silmaril @ Aug 7 2008, 01:49 AM)

Has this vicious circle been broken by now?

The Report Type enum is required in LabVIEW 8.6, but the enum contents are the same whether or not you have the toolkit installed. So this issue should no longer occur when using a VI on two different systems, one with the toolkit installed and one without.

-D

Link to comment

QUOTE (Darren @ Aug 7 2008, 04:50 PM)

The Report Type enum is required in LabVIEW 8.6, but the enum contents are the same whether or not you have the toolkit installed. So this issue should no longer occur when using a VI on two different systems, one with the toolkit installed and one without.

These are good news! :thumbup:

I will consider installing the toolkit again with LV 8.6.

Thank you for clearing this up!

Link to comment

One thing to keep in mind regarding the change to the Report Generation Toolkit. When you build an application that uses VIs that are part of the toolkit, you will run into the name collision issue where some files will be placed outside of the executable.

Link to comment

QUOTE (Aristos Queue @ Aug 1 2008, 10:20 PM)







  1. The LabVIEW Schema palette includes the following changed functions:
    • Flatten To XML—Supports LabVIEW classes and the fixed-point data type.
    • Unflatten From XML—Supports LabVIEW classes and the fixed-point data type. [ :ninja: <<< All the other items had smilies when I finished typing this. I thought this should have a smilie too.]

Though I see that it doesn't seem to handle Variant Attributes yet - which is shame as until the To More Specifc class bug gets fixed, variant maps are one of the more efficient maps and it would have been nice to have had an easy way to save them to disc or squirt them over the network in a human parseable fashion... oh, well next time perhaps ?

Link to comment

QUOTE (crelf @ Aug 5 2008, 11:05 PM)

As they say in the acting profession: "what's the motivation?"
I don't think the Report Gen VIs will ever change their conpane to be by-value. That doesn't make any sense for this API -- files are a system resource that is better handled by reference than by value*. But the under-the-hood implementation may convert over to a lot more classes. Also, new VIs may very well have classes as part of their connector pane for parameters other than the report refnum.

* "But, AQ, I thought you said never use references." No, although there were a couple folks at NI Week who thought I had said that. Let me be clear: I've never said that you should never use references (except for those people who are addicted to references and need to kick the habit). What I have said is that use cases for references are much much rarer than use cases for dataflow, and thus references were less of a priority when we were developing LV classes. My rough estimate, based on two years of observing LV applications from customers and NI developers, is that references are appropriate for about 5% of all class types; the rest of the time the by-value classes are preferred (higer efficiency, fewer race conditions).

Link to comment
  • 4 weeks later...

QUOTE (Aristos Queue @ Aug 18 2008, 09:53 AM)

I don't think the Report Gen VIs will ever change their conpane to be by-value. That doesn't make any sense for this API -- files are a system resource that is better handled by reference than by value. But the under-the-hood implementation may convert over to a lot more classes. Also, new VIs may very well have classes as part of their connector pane for parameters other than the report refnum.

That makes sense.

Link to comment
  • 1 month later...

QUOTE (Aristos Queue @ Aug 3 2008, 10:20 PM)

...the only excuse you'll have for not adopting LabVIEW classes is that even in 8.6 they aren't available on RT and embedded targets (and don't bet on that excuse lasting much longer... :ninja: ).

Any word on that? I just wrote a new template architecture using heaps of LVOOP, and then had to rewrite a lot of if it using a by-ref model (for those playing at home: I chose dqGOOP) because I was reminded that the architecture was going to be used in both Windows and RT.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.