Jump to content

Aristos Queue

Members
  • Content Count

    3,119
  • Joined

  • Last visited

  • Days Won

    169

Everything posted by Aristos Queue

  1. 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 nee
  2. Hunt around in vi.lib. I don't remember where exactly, but someone put in a set of variant introspection VIs.
  3. 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.
  4. 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
  5. 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. Us
  6. 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
  7. 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?
  8. 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 so
  9. 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 futu
  10. "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
  11. :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.
×
×
  • Create New...

Important Information

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