Leaderboard

You are getting trapped inside that while loop that you have nested in the false case of your "deque" loop. (the one with the DAQ assistant express vi in it.

Here's an updated version of the Interface Framework. Changelist: Refactored out the dependency on the Collection Framework. The Interface Framework is now self sufficient. Renamed "Interface" class to "IUnknown" to help avoid confusion. Renamed "InterfaceCollection" class to "InterfaceBag," since it no longer derives from the Collection Framework. IUnknown now contains an Interfaceable object rather than a DVR to an Interfaceable object. (Thanks kugr!) Removed friend relationship between Baby and ISleepableBaby. (Thanks SciWare!) Added several UML diagrams to the documentation. (Use Star UML to view the core document.) Still trying to figure out a better name for the Interfaceable class. I'm open to suggestions... A few other minor things, but I've forgotten what they were. A couple notes on terminology: In COM and .Net when an object supports a given Interface it is said that it implements the Interface. This makes sense in those languages; the code that executes when an Interface method is called is implemented directly in the class. That terminology doesn't make sense in this framework since each Interface is implemented in its own class rather than as part of the core code of the target class. I prefer to say an object exposes an Interface. Sometimes I'll also say an object has an Interface or supports an Interface, or an Interface is implemented for an object. I'll typically capitalize the word "Interface" when referring to the interface classes and objects described in this framework. I'll leave it lower case when using the word "interface" in the general meaning. "Interfaceable" with a capital 'I' refers to the proper noun, the Interfaceable class. When it is not capitalized, "interfaceable" is an adjective describing a class or object that derives from the Interfaceable class. These are the main diagrams I've included in the documentation. Hopefully they help explain how the framework interacts with the classes that are built on it. Other than vi context help I have not yet developed documentation on steps for class developers to take to implement classes based on the framework. In this framework any class that exposes an Interface must inherit directly or indirectly from the Interfaceable class. All Interfaces must inherit directly or indirectly from IUnknown. InterfaceBag is simply a helper object that holds all the Interfaces an interfaceable object supports. This diagram shows the relationship between the framework and the three classes (at minimum) that must be implemented when using the framework. Interfaces are designed to be reused so usually the Interface already exists, leaving the class developer with only two classes to implement. Classes that inherit from Interfaceable override the _GetInterfaces method, returning an InterfaceBag which contains all the concrete Interfaces the class exposes. How the InterfaceBag gets populated with concrete Interfaces is up to the class developer. Two common methods are by initializing the InterfaceBag in a Create method or by adding the concrete Interfaces to the InterfaceBag at design time and making those values the default. This shows the implementation of the Baby class in the attached example. It has one added complexity over the generic implementation; the Baby class has made the ISleepableBaby class a friend, which allows Baby to expose methods that are only accessable through the ISleepable Interface. This diagram shows the sequence of calls that take place when a class user calls the GetInterface method on an interfaceable object. Note that the class developer only needs to implement the _GetInterfaces method in their class. The rest of the work is handled by the framework. Here is a sequence of calls made when a class user calls a method exposed by an Interface. As expected, the class developer has slightly more work here in deciding exactly how the Interface method applies to this specific interfaceable class. ------------------------------------- What can you do with Interfaces? That's a little like asking what can you do with Play-doh. Undoubtedly there are lots of ways to use them I haven't though of. Here are a few ideas I've been bouncing around: - I really like Kurt's Active Object pattern. It might be worthwhile to create an IActiveObject interface. Still thinking about use cases on this... - I also like using the Observer pattern to separate program logic from the UI. Maybe an IObservable interface? (Though Event Refnums being strictly typed presents some difficulties.) - IPublisher? ISubscriber? - .Net documentation also provides some hints on potential uses. ISerializable? IPersistToFile? - Or getting back to what started me on this journey in the first place, IMeasureVoltage? IMeasureCurrent? [Edit Aug 3, 2010 - Removed pre-release version. Get current version from the Code Repository.]

Here's my heavily-biased weigh-in (disclaimer: I'm on the team that created VI Tester): I haven't used NI's UTF (but I've seen it demo'ed). It seems to have great features for knowing whether you are testing 100% of your code and need reports to prove it. Of course, I have used JKI's framework, which is great if you're interested in using a proven software engineering architecture (xUnit) for software testing that's implemented in LabVIEW, for LabVIEW developers, by LabVIEW experts who use it themselves to write and test commercial software products written in LabVIEW. With VI Tester, writing unit tests is fun, since all your tests are written in LabVIEW. This also means that you can reuse code within your tests, and employ object-oriented techniques in the design and implementation of your tests. JKI uses VI Tester for testing all the software it writes and we're going to keep making improvements over time, including possibly integrating it with other products like VIPM's package builder (JKI currently uses VI Tester to automatically run unit tests on all our VI Packages [software reuse libraries] during the build process). Update: I'll also add that there is a wealth of information (book, websites, etc.) on xUnit, including: test architectures, design patterns, best practices, tutorials, etc. This means that there's a wealth of training materials that apply almost directly to how to use VI Tester. Thanks, -Jim

dannyt seems to have been more insightful than I was and figured out what you were actually going for. You're going to want to learn up on state machines (I see 3 states, minimum: idle, login, and logout). You'll have a parent VI which calls either main.vi or login.vi. You'll need to decide how you want to keep track of whether the user is logged in or not - you can use globals and call the global where ever needed or you could use a shift register in the parent vi and have the state passed as an input to main.vi or login.vi.

Here's a quick and dirty way of doing what you want. It just shows or hides one window or the other based on a VIG. Run the Start Engines VI since it is the new top level one. It will run both the Login and Main windows. One will be shown the other hidden. Once the user presses the button on that window, it will hide itself and show the other, but they are both constantly running. EDIT: sorry I posted it in 8.6, now there is one for 8.5