Aristos Queue

But I can't open any vis in this file,

it assert that the version of the vis in this file is newer than what i used!my labview is 8.20,why??

Are you using a beta copy of LV8.2? These were written in the final release candidate and won't open with any of the beta editions.

At NI Week, Christina Rogers showed her refactoring of the Getting Started Window using LabVIEW classes. The source code of that refactoring is now available. Here is the link to her blog.

http://eyesonvis.blogspot.com/2006/08/obje...ted-window.html

create a Project, create new, blank VI and close it immediately: you'll get the defer decision button. If you remove the VI from the project later, then you can close and remove it from memory. But that are more steps to take then I "like" . A "close and remove from Project" button would be fine in this situation. Ok, that could become difficult, because of e.g. unsaved SubVIs, etc, but I think, that "solution" is worth thinking about?

:headbang: ARGH. That. Is. Not. Supposed. To. Happen. I really thought that had been tested.

If the VI is truly a virgin VI, then closing it should automatically remove it from the project. Now, if you've added it to a library, then it isn't virgin any more because its name has been changed and the library maintains a link to it. But if it is just New>>Project, followed by New>>VI, and then you close the VI, that's just supposed to disappear. Are you sure you didn't do *some* edit to it?

Ok, I have a favorite tip that I was giving out at the LAVA dinner during NI Week which it seems no one heard before.

Who likes the autotool? You know, when you go to the Tools Palette and set it to automatically change your mouse cursor for you as you move over the diagram. No more Tab key! Sounds great, but a lot of people don't like it. A LOT of people. They're genuinely surprised when LV developers like me say things like, "Yeah, I always have the autotool on and I don't know any time since LV7.0 when I wanted to turn it off." How can this be? The control key.

If you have the autotool on, the mouse cursor changes to "the most needed tool on this region of the screen." Sometimes that means each tool gets only a small region of the screen. I hear people want to turn the autotool off when they try to move a boolean button -- they can get the operate tool and the text tool, but they can't find the very small region to get the pointer tool.

Hit the control key.

If you hold down the control key, it is defined to give you "the second most needed tool on this region of the screen."

The first most needed and the second most needed are both based on a lot of user feedback. The autotool was introduced in LV6.1, and the control key mods came in LV7.0. Since then it's been pretty nice. And those of you who tap the Tab key habitually can just slide your hand down the keyboard and tap the control key instead. Oh, and it works for both left and right hands.

Interestingly even though you cannot overload operators in LabVIEW you can "overload" method icons, that is create a method with exactly the same icon. This has the same result in code readability than operator overloading, since icons define "what you see" instead of VI-names.

True. Not much I can do about that. ;-) But at least at the names level I can make sure that the common errors introduced by overloading don't happen to LV programmers the way they happen to C++ programmers. I've spent days debugging that type of error in C++.

Replace the Class object constant with a customizable "constructor-vi" and you are done.

The word you're looking for is "XControl." An XControl of the class type is the initialization that you describe.

And, those of you who don't have Pro edition, forgive me... I didn't know when I posted before that XControls weren't in the base package.

One thing however annoys me quite a lot in the article. It kept repeating that the lack of properties in LV OOP is due to the fact that scientists and engineers are not formally trained for programming and therefore couldn't use properly any fancy features of programming languages.

That should be taken as "most programmers in any language can't use some of the features from C++ that were left out."

James Gosling was the designer of JAVA. He once gave a presentation on why JAVA's design decisions were made. One thing I will never forget is why JAVA does not have operator overloading like C++ does. "People were doing dumb stuff with it... like using the left shift operator for output!" The standard template library for C++ uses the left shift operator. Gosling's inditment was that the code becomes hard to read if these symbols become so context dependent that the code is no longer generally understandable. In the case of the left shift operator, that's probably ok because very few of us actually use left shift these days -- we don't need to squeeze that bit of performance out when multiplying by two anymore. But as the + became used for add, concatenate, append to file and other things, code clarity was lost. So JAVA didn't include this feature.

C++ is a masterpiece of language design in so many ways. It has capacities to express concepts beyond the dreams of most developers. It is the language for James Joyce. But most of us read Dr. Seuss. Many of C++ most advanced features are never used, and when they are, they just raise questions among a lot of other developers about "what the heck does this do?" A classic example is "class X : protected Y { };" What exactly does that do to the inheritance rules?

JAVA tried to refine OO. LabVIEW aims to take it to a whole new audience. Over time, features may be added that only show up in the Pro version. But the fundamentals were rolled out in LV8.2, and these are the pieces that will be common at every level of LV expertise. It isn't so much that LV users can't use the fancy features, its that many don't want to worry over whether they should or not. LabVIEW lets you focus on the project you're working on more than the code you're writing to do that project. We constantly balance power versus interference. It is our strength. And our weakness. And, fundamentally, it is our niche in the programming world. We aim to fill it well.

Which version you want to use, depends on your needs.

"Real" OO implementations (with inheritance,...) are Endevo GOOP, Goop developer 2.0, and LabVOOP:

Endevo GOOP has an impressive graphical Project tool,

LabVOOP is native LabView.

The official NI position is this: Both GOOP classes and LabVIEW classes are useful. They serve orthogonal use cases and you may well use both types in the same application. Comparisons should be based on program requirements and choice made accordingly. The core data of your GOOP Toolkit class may be a LabVIEW class. For details on this, take a look at this thread:

http://forums.lavag.org/index.php?showtopic=3788

This was reported to R&D (# CAR ID 40LHJ4J1) for further investigation.

(Jim, what follows is mostly stuff I already sent to you in e-mail, but it seems useful to post here.)

I am thrilled at all the different implementation mechanisms that Jim has proposed. But there's an underlying assumption that he makes: that we are searching for the One True Way to implement a reference class. I disagree. I think we're searching for all the good ways to implement references, and that there is no One True Way. Different implementations serve different use cases, and I think in time LV users will standardize around a set of reference models, not one single model.

Example: Jim argued that the programmer should make "Check In.vi" and "Check Out.vi" private. That's true if and only if the programmer has created wrapper VIs for all the member VIs of the original class and replicated them on the reference class and if there is no performance gained from doing a Check Out, doing multiple function calls, and then doing a Check In.

• Making the check in/out functions public is a model where the data is mostly used by value and the reference is created only occassionally for a particular value. It is similar to "Index array, do a bunch of modifications, replace element in array."
  
• Making the check in/out functions private is a model where the reference model is the primary way the class is used. That model is like "Tell Array Y to do the following modifications to index X."
  

Both implementations are valid concepts, and both are useful depending upon the architecture being implemented. Many customers have argued that NI should put forth a standard by-reference implementation so that everyone uses the same system, but I've got half a dozen "standards" that I can envision, each serving a different design goal. I'm more comfortable letting conversations like this one run for a while before NI starts putting an official standard together -- I think we need to see the full range of what develops in the world before anyone can definitively say what the standard(s) should be.

Keep the ideas coming ... most folks (both inside NI and outside) don't agree with me, but I truly think that every LV developer who moves beyond a set of Express VIs on a single diagram will eventually consider classes as normal and standard as VIs. We've got to get it right in these early years.

PS: Jim described his case #3 as the hands down winner. In my eyes, the "con" would be:

* Reference API has to supply all possible permutations of operations for efficiency. If I have a reference to a Numeric, I need my reference class to have methods for Add and Multiply. I also need to have "Square and add another square then take the square root". Otherwise I'll have to do a check in and check out between every step of the mathematics (very inefficient). With the Check Out as a public function and the a class as the queue's type, I can check out and do a whole stream of operations, still with my class shield in place to protect the data from arbitrary changes, and only do a single check in.

One subset of this which easily confuses users is if you've Ctrl-C'd some VIs.

Even if you close the calling VIs they would still remain in memory (in the clipboard, also visible in the VI hierarchy window), but it would not be clear that they are. This could actually be quite a common use case. I don't know whether LV 8 with the project and the seperate application instances did something to change this.

This is still true in LV8.2. The clipboard is a caller that can hold VIs in memory. A bit odd, yes, but I can see how it got this way. If the clipboard didn't hold in memory, if it just recorded name/path of VI, then doing "ctrl+X" on a diagram to remove some VIs, you might be prompted to save those subVIs. And when doing the paste, you might get a conflict with another subVI of the same name already in memory ... did you mean to paste the previous VI of that name or the one you loaded between cut and paste? It gets tricky.

Suggestions?

:!: [About an hour later...] I was working with a graphics program. I closed the program. It asked me if I wanted to keep the data on the clipboard when exiting. Maybe that would be a good idea for LV if you close a VI and that VI is still on the clipboard. ???

What I'd like to have is the possibility to close and remove VIs from memory, if I don't need them any more.

The Defer Decision button appears ONLY when a VI's front panel is closed and the VI *cannot* leave memory. There are fundamentally three reasons why a user VI cannot leave memory:

0) It's front panel is open

1) It is a subVI of another VI and that other VI is not leaving memory

2) There is an open VI reference to the subVI

3) A special case involving VIs in untitled libraries -- I forget the details of it -- but it basically is the same as reason #1, only instead of a caller VI, it's the owning library holding onto the subVI.

When you close the front panel of a VI, that removes reason #0. If the VI has unsaved changes, that's when we prompt. And the VI is either able to leave memory (none of the other reasons apply) or it is not able to leave memory (one of the reasons does apply). If it cannot leave memory, you'll get Defer Decision.

We did consider adding a Revert button to the dialog -- so you would have the option to "close and keep changes in memory" or "close and reload VI from disk so in-memory changes are lost" -- but, first, adding another button was exactly the opposite of our goal and, second, we'd have to gray out that option under a lot of conditions because the subVI was in use.

If you can find a case where a VI is giving you the Defer Decision option and you know that none of the above reasons apply, I'd like to know about it.

Oh, and regarding criticism of LV -- I'm the one showing up to read an independent user forum. I've gotta expect that the reality doesn't match the marketing literature. If it ever does, well, LV will be complete and I'll have to go find a new job. Just make sure to post a bit of the pleasure with the pain -- so I know what features not to tinker with. ;-)

7 Buttons? Where? uhmh? hu? tell me more ...

The dialog whose picture you posted has 12 different versions depending upon conditions. One of those versions requires 7 buttons. Even the simple version that you posted caused many complaints about people who couldn't tell whether the VI was leaving memory or not (yes, the large block of text tells you, but for many, that text they read once and assume its the same every time). Then there was the fact that the buttons drifted around -- sometimes Save and Don't Save are vertically arranged. Other times they are side-by-side. Finally, that dialog appeared multiple times because we actually needed to ask different questions for different VIs -- a single close could result in multiple VIs closing, some staying in memory and others leaving memory. And then there was the complete lack of explanation as to why sometimes the Cancel button was grayed out. Or, if it wasn't grayed out, what exactly you were canceling. Were you cancelling Close All? or were you cancelling the close of one VI during the Close All? That dialog was the source of a huge number of complaints. Creating a UI that took all possible scenarios into account was non-trivial in the extreme.

In regard to variant, I am missing the type string from the flatten/unflatten to string primitives. This make variant introspection, in the spirit of the OpenG variant tools, pretty much no longer possible for new data type.

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

Here's a video showing the Tribot in action.

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.

By just using a standard cluster, you don't get the benefit of class inheritance with the automatic 'polymorphism' of method VIs when wiring superset clusters. That's a nice benefit.

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.

Also, I'd like to see all the method VIs, and inherited method VIs, accessible with an Invoke Node with the object wired in as the node's reference input. Then it would feel more like I'm using an object rather than a kind of polymorphic VI.

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

And what about back doors. Has anyone placed one in software they have released?

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.

What is that "defer decision" button good for, if the VI is not a subVI and I want to close it?

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?

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?

The only missed boat I see here is that it would have made sense to have the standard Property Node be able to read and write the cluster elements of the object. I don't think that would be hard for the LV developers to implement.

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

Startup time is very much improved(!) and object oriented programming (GOOP) is embeddeed now!

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

Does anyone know if (and how) i can convert endivo GOOP classes to the new labview 8.2 classes?

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.