Jump to content

Rob Calhoun

Members
  • Content Count

    5
  • Joined

  • Last visited

  • Days Won

    2

Rob Calhoun last won the day on October 1 2013

Rob Calhoun had the most liked content!

Community Reputation

2 Neutral

Recent Profile Visitors

2,394 profile views
  1. Here are three things that make the VI Tester behave in unexpected ways to a new user: Test Cases that do not have any test methods do not appear in VI Tester hierarchy. (Maybe this is a feature, but it's not what I would expect.) After creating and saving a new test method the Test Case still does not appear in the VI Tester hierarchy. This is because the Test Case (class) has not been saved, so it still has no test methods from the point of the VI Tester Only test methods that start with the word "test" (at least this appears to be case-insensitive) are considered test methods. The first of these should get fixed; the hierarchy should show the Test Case even if it has no methods. The second is a design flaw in LabView that causes no end of trouble. LabView classes have this irritating behavior of being both cross-referenced (a method knows it is part of a class, and a class knows it is part of a member) AND comprised of multiple files thus requiring multiples save operations. Not only is it causing trouble here, the design makes it is easy to quit LabView with the class in an inconsistent state. Back to the VI Tester. I can't figure out the logic behind the third item above. I agree it's a convention, and conventions are good, but when would you want a method that is a method of a Test Case class, but not one of {setUp|tearDown|testMethod}? If this is desired (I can accept there are valid use cases), is there a less quirky implementation? This one is not very friendly to non-English speakers (or English-speaking newbies, for that matter.) I was kicking around whether one could solve this by making Test Methods from a dynamically dispatched template, but that doesn't really solve anything. Anyway, the name requirement needs to be spelled out in bold face type. At present the VI Tester is quite frustrating to use at first because it's hard to figure out what you need to do to make a test that will be recognized. (I could run the example tests, but I couldn't run any of my own!) -Rob
  2. This is a funny (well, sad, really) thing about LabView these days; walking the project hierarchy is mind-bogglingly slow. We wrote a quick-drop-like tool (before quick drop) for user VIs. We used to scan the project hierarchy so we could properly assign each VI to a project and ignore irrelevant ones, but it was hundreds of times faster to simply do a recursive filesystem search for all labview files below the .lvproj file, so we switched to that.
  3. This is a good tip! I've used LabView for years and never once clicked on one of those buttons, low and behold, there they are. Since there does not seem to be a way to bind a keystroke to {Tools -> VI Tester -> New -> Test Case}, the buttons save quite a bit of navigation. (I'd still rather have key bindings for New Test Case!) Rob
  4. This actually improves workflow quite a bit. Now I can right-click on testExample.vit and select "New from Template". Thanks!
  5. I get the same error when trying to open the VI tester from the LabView Getting Started window. (Windows 2008 R2 Server, VI Tester 1.1.2.164-1, LabView 2010 SP 1. If I open a project first, the VI tester opens fine. There's no actual need to open the VI tester from the Getting Started window. However, the Getting started guide specifically recommends doing exactly that, which is why I encountered it. It might be good to put a note on that page suggestion starting with an empty project.
×
×
  • Create New...

Important Information

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