What's new for LabVOOP in 8.6?

[Aristos Queue]

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, 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. ]
   
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!

[PaulL]

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

1. 
   

• 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.]
  

I had just navigated to LAVA to do a search on "LVOOP XML" (after reading this http://zone.ni.com/reference/en-XX/help/37.../using_classes/) when I saw your post. Awesome! Thanks!

[Michael Aivaliotis]

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

1. LabVIEW 8.6 includes enhancements to LabVIEW class error reporting that might result in fewer unbroken class items listed in the Error List window.
   

Isn't that a typo? Shouldn't it read: "that might result in fewer broken class items"?

Because fewer unbroken means more broken right?

[MikaelH]

QUOTE (Michael_Aivaliotis @ Aug 2 2008, 10:59 AM)

Isn't that a typo? Shouldn't it read: "that might result in fewer broken class items"?

Because fewer unbroken means more broken right?

That text is copied from the LV 8.6 Feature and changes:

http://lavag.org/old_files/monthly_08_2008/post-941-1217641608.png' target="_blank">

..I like the VI file size improvment.

All VIs are now half in file size. :thumbup:

Cheers,

Mikael

[LAVA 1.0 Content]

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

[crelf]

QUOTE (Aristos Queue @ Aug 1 2008, 05: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.
  

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">

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

[Darren]

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

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

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

[crelf]

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

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...

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

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.

[Darren]

QUOTE (crelf @ Aug 2 2008, 04:22 PM)

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

He's worked in LabVIEW R&D for longer than I have, so I'll let you guys figure out who he is.

-D

[Yair]

Ooh, is it Dread NcKaskle? (groans welcome)

P.S. Nice stuff, Stephen & team. It looks like I'll actually be using 8.6. :thumbup:

[Darren]

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

[crelf]

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:

[Darren]

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

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

I honestly don't know what we're going to do yet...one thing I was thinking was that we'd keep the Report Gen instance information within the class data, as opposed to using a separate shift register database (as we're doing now). Also, I think the shift register database approach is only used with the HTML report type, since all the other reports (Standard, Excel, and Word) use references (based on their ActiveX roots). So splitting the class wire for Standard, Word, or Excel reports wouldn't create a "new" report in that case. We're effectively mimicking that behavior with the shift register database for HTML reports.

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

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

I'm very interested to hear what you guys have to say about LabVIEW 8.6, so I'm trying to check in frequently.

-D

[silmaril]

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........).

Has this vicious circle been broken by now?

[Darren]

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

[silmaril]

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!

[gmart]

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.

[gb119]

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

1. 
   
   
2. 
   
   
3. 
   
   
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.]
     

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 ?

[Aristos Queue]

QUOTE (Gavin Burnell @ Aug 14 2008, 04:16 PM)

oh, well next time perhaps ?

Is there a CAR on that?

[Aristos Queue]

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).

[crelf]

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.

[gb119]

QUOTE (Aristos Queue @ Aug 15 2008, 12:57 AM)

Is there a CAR on that?

No, but at least there's now a product suggestion made in the right place...(as opposed to moaning about it on LAVA

[crelf]

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.