Aristos Queue

Hunt around in vi.lib. I don't remember where exactly, but someone put in a set of variant introspection VIs.

A more interesting application -- something that definitely couldn't be done with the previous RoboLab RCX motors: http://mindstorms.lego.com/MeetMDP/MBrandl.aspx The link to the video is at the bottom of the page.

LabVIEW classes aren't exactly standard clusters. For one thing, the method VIs *do* get the benefit of automatic polymorphism. Suppose you have a subVI that takes a Parent class in and gives a Parent class out, and on the block diagram the input connects to the output (possibly passing through other nodes along the way). We do a syntactic analysis of the subVI's diagram to prove that the runtime type is going to be maintained from start to finish. If the subVI's diagram passes that analysis, then when you drop that subVI and wire a Child class to it, the output will automatically downcast to a Child class. Why is there no emoticon for sobbing? The Invoke Node would make you "feel more like I'm using an object"?! This makes me really wish that we'd had OO before VI Server. VI Server has conditioned everyone all wrong. The Invoke Node is identical to a subVI call... only it doesn't have an icon so it isn't understandable across human languages, and it doesn't have a conpane, so inputs and outputs are just stacked arbitrarily. The Property Node actually adds some useful syntax (stacking multiple function calls together). The Inovke Node just puts a big ugly text block on your diagram instead of an elegant subVI node. Please don't ask for support for the Invoke Node... I'm not sure I could write code through the tears.

Some of you may know me from other LV venues -- info-LV, NI's DevZone. I've only recently created an account on LAVA mostly because of the discussion on the info-LV mailing list where some are claiming that forums are better than mailing lists, so I figured I'd come look around. And, being a LabVIEW R&D developer, my greatest interest, naturally, is the bug list and the comments about the newest versions. So I read through many of those over the last couple days. And I'm amazed. There's a lot of discussion about LV8.0, but there are some pretty big features that get almost zero mention. Users discussing any software are going to focus on the bugs and the things that went wrong -- that doesn't bother me. But there are some real gems in the 8.0 release. So I thought I'd list some of them here, just to see the response generated. 1) XControls : This, in my opinion, is the #1 reason to upgrade to LV8.0. I think this is the answer to many of the UI complaints made about LV. This feature is invaluable to making reusable user interfaces. It

I've been known to put easter eggs into software. There's one in LV (which I'm sure you can find if you search around on this site a while). When putting it in, I followed nearly all of the standard software design requirements that we have for code changes. About the only part I skipped was the full team opportunity for comment on the feature. The change was buddied by two other developers, and I documented the .ini token in our official lists (though I may have been a bit vague about what that token did *exactly*). I filed a test plan in the test plan database so it gets tested every release. Every release I get someone who walks up to me and in a very quiet voice whispers, "I got assigned your test. Nice egg. It works." And the conspiracy goes on. ;-) For an Easter egg you have to consider all the aspects you consider for any feature: impact on memory, impact on performance, impact on user interface, impact on localization, impact on maintainability of the code base. What I've learned as time goes on is something I should've known from college -- you don't have to keep it a secret from your team. Most developers will enjoy it and help out, and having those other people know about it will give them a chance to advise you against something that "seems like a good idea at the time." *ahem* If you've kept all the above impacts in mind, even managers generally think its cool -- provided you're done with all the assigned tasks, of course. Further, some of those Easter eggs can turn into features. For example, in LV8.0, I put in a way to replace the LV Icon Editor with a VI so that I could write a VI that would call a third-party icon editor. That was liked enough that we decided to document it. When you get right down to it, a well-done Easter egg is just a well-done feature that doesn't get as much publicity.

Hm... Well, the Defer Decision button only shows up when the VI is not going to leave memory. If the VI is not a subVI then I can only assume one of the following is true: 1) You have an open VI Server reference to the VI 2) The VI is part of a library and the library is currently holding its member VIs in memory 3) It actually is a subVI... check the VI Hierarchy If you really can't determine why the VI is staying in memory, report the bug as best you can. But tell me this... do you like the new Save Changes dialog better than the 7 button monstrosity that existed before?

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

The cluster elements are accessed through bundle/unbundle on the diagrams of member VIs. When exposed outside of the class, we require you to go through member VIs (for a variety of reasons). At one point, we were going to allow member VIs with a specific conpane to be accessed through the Property Node (that's why the property node allows you to wire to it). Alas, this was dropped for lack of priority. It is "syntactic sugar" -- it makes it a bit easier to set a batch of properties, but wasn't required for the release since you can just drop all the subVIs. It would not surprise me if a future version picks that feature up, but, standard R&D caveat, no promises. ;-)

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

:thumbup: An updated URL is now available: LabVIEW Object-Oriented Programming: The Decisions Behind the Design This location is the permanent home of the document. If there are updates to the document, they will be made at this URL.