Aristos Queue

QUOTE(i2dx @ Aug 19 2007, 02:05 AM) What is Europe? QUOTE(i2dx @ Aug 19 2007, 02:12 AM) www.labviewforum.de currently: 2900 users with 33.903 posts You'd think that of 2900 users, more than 33 would post something. And who only posts 9/10ths of a post? Definitely a strange place, this Europe of which you speak.

You didn't even mention the LAVA logo appearing on the LV splash screen.

QUOTE(jpdrolet @ Aug 18 2007, 03:26 PM) AH. That looks like the elegant solution that I was hoping for. Yes, that looks like good LV style. We should record that somewhere; add it to the recommended design of block digrams.

QUOTE(yen @ Aug 18 2007, 01:33 PM) I've never even heard of this option. When you say "undocumented", that would include the internal docs. Where did you find such a thing?

Remember that the object is not holding onto the queue. The VI is holding onto the queue. The object is just holding onto a number. The Endevo objects are still in existence because the VI that holds the objects is still running. If it were to go idle, your references to those objects would likewise go idle. You described them as referenced clusters. There's no such thing as references in LV per se. There are numbers that are indexes into an array of data. That array is still live because the Endevo tool is still running in the background.

QUOTE(NormKirchner @ Aug 17 2007, 11:19 PM) Some of the string functions work with the picture string directly (most do not). http://forums.lavag.org/index.php?act=attach&type=post&id=6680''>http://forums.lavag.org/index.php?act=attach&type=post&id=6680'>http://forums.lavag.org/index.php?act=attach&type=post&id=6680

QUOTE(silmaril @ Aug 18 2007, 01:40 AM) No. What it means is that if the library is part of your project, you just drag and drop items from the project window to the diagram. If you've created a library for distribution (as a toolkit for others), then add a .mnu file that gets installed with the library. Your misinterpretation of my comments is a good idea however. I'll pass it along.

The queue references get invalidated when the VI that created them goes idle. Could this be the source of your problems?

QUOTE(Daklu @ Aug 17 2007, 05:19 PM) The biggest objection I have to this solution is that it requires LV to evaluate all possible tests. In this particular case, the tests are all cheap, but one could imagine one of the tests being expensive (i.e. "if this number is prime" or "if this number is found in this array"). Even though LV will work to try to schedule the tests in parellel, there's still the cases where you shouldn't run one of the tests at all unless the previous test fails (if device is not installed { fail } else if device is not enabled {fail} else {success}). I think we should look for an idea that doesn't evaluate all the code paths.

QUOTE(Jim Kring @ Aug 17 2007, 08:55 PM) Depending on your view of class testing, this shouldn't be a problem. If the only part of your class that can be invoked is the public API, then a test harness that validates the public API is all you need. If there's a bug in an underlying private subVI, but that bug doesn't affect the public functionality, then who the heck cares? But, yes, your comment is noted. :ninja:

QUOTE(jdunham @ Aug 17 2007, 05:56 PM) I wouldn't take this route. Again, the library should be a distribution unit. Your test harness never gets distributed with your production code. So they shouldn't be in a module together. The test harness should be in the project that is used to create the classes. That's the association point. QUOTE(Omar Mussa @ Aug 17 2007, 06:04 PM) So, in the end, a project does have a 1 to 1 relationship with a LV Application (even though it is possible to 'try' to make it 1 to many) -- a definite shortcoming of the project environment. One man's shortcoming is another man's intended design. :-)

[LATER] Oh, I just thought of another solution that may meet with boos from some people... the Formula Node can do the if-elseif-else type work. You could use it to either do your calculations directly or to generate the aforementioned enum. It isn't dataflow, but it might be cleaner depending upon what you're testing.

QUOTE(Daklu @ Aug 17 2007, 03:34 PM) Nested case structures is as close as you get. If (x) blah else { if (y) blah2 else { etc... } }

AQ's general thoughts on project, library and VI relationships: A VI is a function dedicated to a specific task. It has no particular allegiance to any particular application. It doesn't care who calls it... it does what it does when it is invoked. A Library is a collection of related VIs. Some libraries are dedicated to a particular task: .lvclass libraries are dedicated to defining a new data type. .xctl libraries are dedicated to defining a new control. Libraries are coherent distribution units -- all the VIs therein should distribute together. The VIs that test a library's functionality should not be in the library since you don't generally want to distribute your test harness. Again, libraries have no allegiance to any particular application in LV. A project *is* a particular LV application. There is a one-to-one correspondence between "something I as a user generate to be an end product" and a single .lvproj file. There is some leniency to this one-to-one relationship if a single chunk of VIs are used to build multiple build targets -- perhaps both an exe and a dll, or multiple flavors of source distribution, for example -- but these are just flavors of the same general deliverable. The project should include the test harness for the deliverable. A VI and a library are reusable components. They may be used by multiple projects. If you intend to have a component that you share between multiple projects, then there should be a project for that shared component itself. That project should contain the test harness for that component. The other projects that just use the shared component don't include the test harness for the shared component. In the most extreme of stringent coding practices, the project for the shared component has a Source Distribution build. It is used to generate a separate copy of the source code which will be used by all the other projects. The other projects do not ever reference the original source code of the shared component. This protects against unintended edits, and allows you to always regenerate from the shared component's project a clean version of the shared component. The post above said "that lvlib is a namespace and has a one-to-one pairing with VIs". The Library actually has a one to many relationship with VIs. Each lib contains multiple VIs. You should package together VIs that are related, to the extent that feels reasonable to you. Some libs are very small. The Analysis library that ships from NI has 600+ VIs in it. In the words of Yoda, "Size matters not." It is a question of how related the functionality is and whether the VIs are intended to be distributed/used together. You can use sublibraries to give further breakdown if that is useful. Make VIs private or protected whenever possible. It helps your debugging later if you know that no one else could possibly be calling a given VI. And it makes it easier to change conpanes if you know that no one else is using a given conpane. My personal goal is that all VIs should be owned by either an XControl library or an LVClass library. Plain libraries should only own other libraries for packaging and distribution purposes. This is in accord with the maxim "All bits of data may be thought of as part of some object; all functions may be thought of as actions taken by some object." Do I actually keep to this goal? No. LabVOOP still has inefficiencies in some places, and sometimes I get lazy. But I'm working toward that goal and do believe it is viable. All the VIs for a single project go in a single directory unless they are components intended to be shared among many projects. Within that single directory, I recommend creating subdirectories for each library. I do not recommend that you have any further disk hierarchy. If you create folders within your libraries, so be it, but don't make directories on disk that reflect those folders. Why? Because folders are the organization of your library for presentation as a palette and for providing scope for VIs. It is really annoying to want to change the scope of a VI and have to save it to a new location to keep your disk organization consistent. And it serves no purpose. If the library is a coherent distribution unit, then when you're on disk you're supposed to be moving the entire library as a chunk. Some people complain that that makes it hard to use the "Select a VI..." item in the palette. But I suggest that is what drag-n-drop from the project is for. Use the project window as a pinned palette during development. When you deploy, deploy the library with a .mnu file that is part of the regular palette hierarchy. All of this can feel like overkill for a single developer by him/herself. But I find that these guidelines help avoid cross-linking problems, debug problems and distribution problems even with my own projects that aren't shared with any other G developers. All of the above are my PERSONAL thoughts and should not be taken as NI speaking. I am NOT a full or even part time G developer. I do C++ and G is my hobby, so take my advice with a grain of salt. But, on the other hand, I do spend a lot of time talking about and thinking about what the right way to do things in G is, and I know how the internals are designed. At any rate, its your call how valuable you think all this advice is. PS: If your clusters are already typedefs, put the typedef into the project window, popup on it and choose "Convert Contents of Control to Class." This will help you on your way to converting your project over.

QUOTE(Daklu @ Aug 17 2007, 02:57 PM) The syntax is in the online help for the case structure. In general, wire the variable to the selection terminal (the '?' terminal) and then put the test in the case selector. For numerics: ..1 is anything less than or equal to 1 3..5 is anything between 3 and 5 inclusively 4 is just 4 4.. is anything greater than or equal to 4 default is anything not covered by any case ..1, 3.. is anything less than/equal to 1 or greater than/equal to three.

QUOTE(Ben @ Aug 17 2007, 11:02 AM) It is one of two sources. The other is directly from the Zen koans themselves. I found it in the koans but didn't really grasp the concept until Goedel, Escher, Bach. Something you should know about GEB... the book has two main divisions. The first half is incredibly good. The first half of the second half is good. After that it bogs down. I was talking to a CS professor of mine. He asked if I had read the book. Chagrined I said that I had gotten through 3/4 of the book, but just couldn't finish that last chunk. The prof said, "That's ok. There's not a faculty member in this department who was able to force themselves through that last chunk. Really, it won all the awards for the first half." So if you similarly grind to a halt, you're in common company. Those few I have met who actually finished it say the trail of the book is a rehash of the first half in case you didn't get it the first time, but with more rushed writing style.

This issue has been reported to R&D (4CG9B3J1) for further investigation.

QUOTE(tcplomp @ Aug 11 2007, 01:05 AM) One user reports that it also affects DAQmx, but I have no confirmation of that at this time. It is definitely possible. This issue has been reported to R&D (4CG9B3J1) for further investigation.

QUOTE(Tomi Maila @ Aug 17 2007, 02:48 AM) Known issue. If you just change the name of an element, the type isn't updated. You need to make a change that changes the type itself. Workaround: Add an element to your cluster, do File>>Apply Changes, then delete the element. This will get the other elements to update to their new names.

I don't know the general answer. Use the memory allocation tool (Tools>>Profile>>Show Buffer Allocations) to see whether a given cast is inplace or not.

QUOTE(Darren @ Aug 16 2007, 09:39 PM) So if you want smooth scrolling, just use 1x1 picture controls right? :-)

QUOTE(MikaelH @ Aug 16 2007, 10:47 PM) I think it is fairly awkward to call that a cast. When I cast from 8bit integer to 16bit integer, I don't create any new information, I just rearrange the info that is there. The same is true with casting a string to an array of bytes. When casting a parent to a child, you really are creating information ex nihilo. For LV to offer a primitive that does this sort of casting for an arbitrary class would be a complete violation of encapsulation. Suppose that the parent allows you to set values in the range 1-10. The Child class overrides the SetValue method and constrains the value to be 1-5. A user could construct a parent class with a value of 10 and then force construct that as a child, resulting in an invalid child class. Neither C++ nor Java allows you to cast a value of the parent class as a child class. I don't know of any that allow this sort of thing. You can, as I did in my VIs, construct/initialize a child from a parent, if the particular parent/child relationship finds that to be appropriate. But a generic cast of this sort would be a very bad thing for any OO language to support. Languages do exist that allow you to cast a *reference to parent* as a *reference to child*. That's a very very different thing. Let me go one step further and say that in the vast majority of cases where you might think you want this ability, you've actually got the wrong relationship between the classes. Instead of inheritance, you should have containment. The "child" class should actually contain as a private data member an instance of "parent" instead of one inheriting from the other. Thus the parent data gets constructed at time N and at time N+1 the child data gets constructed with that parent data as a data member.

QUOTE(MikaelH @ Aug 16 2007, 05:20 PM) You mean like this? http://forums.lavag.org/index.php?act=attach&type=post&id=6658''>http://forums.lavag.org/index.php?act=attach&type=post&id=6658'>http://forums.lavag.org/index.php?act=attach&type=post&id=6658

ARGH! It's the "VISA" datatype in private data control bug!!! Here's what you have to do... go back to the 8.2 version of your class. Load the class into memory. Open the private data control and resize the VISA control. (You can actually make any edit to the private data control; that one happens to be safe to do without changing your data type at all.) Then you can save the class into 8.5 and it will load correctly. This is the same bug earlier encountered by another LAVA user.

QUOTE(Tomi Maila @ Aug 16 2007, 02:54 PM) Yes, that does seem like something useful that NI could do. Having said that... The LV features for "Save As on a VI" and "Add VI to library" are already public. The private functions for replacing a control are known by many folks. This is the sort of tool that LV users could write with some ease, I think.