Aristos Queue

The following bug exists in 8.2 and 8.5. It will not be fixed in the next release of LabVIEW. If loading an XControl triggers the load of any VI that uses the XControl (either by hosting on the front panel or using property/invoke nodes on the block diagram), then the VI that loads will be broken. In the vast majority of cases, this is an expected break of the VI because it is a recursive use of the XControl (such as hosting the XControl on its own Facade VI). Clearly such VIs cannot be expected to run. However, when an XControl uses a LV Class, the class will load all of its member VIs, which might use the XControl. Since the XControl doesn't actually use the particular member VI, there is no recursion, and customers might reasonably expect that the VI would not be broken. However, because XControls are expected to be runnable even when the VI that hosts them is in edit mode, we actually end up breaking the member VI as it loads into memory because it wants to run the XControl, but the XControl is not finished loading itself. A user might go for a long time without noticing this break, because as soon as you edit any VI related to either the class or the XControl, the member VI will notice that now the XControl is fully loaded, will recompile itself, and thus be good. The only symptom that would be noticed during development is a VI that always has unsaved changes because the VI had to recompile. But when you try to load the app and run it without making any edits, or when you try to build it as a built application, then you run into problems. This might be quite late in your development cycle, when it would be really frustrating to change your architecture. To avoid this problem, if your XControl uses a class, do not use the XControl in member VIs of the class. If your class uses an XControl, do not use the class in the XControl AND do not make the class a sublibrary inside the XControl (because libraries always load their sublibraries, this results in the same load order problem described above). The changes necessary in LabVIEW to fix this load ordering problem are extensive. LV R&D cannot predict what release of LabVIEW will have a fix for this bug.

0) Because reading the FP terminal has always been the trigger to unlatch the boolean. 1) Because sometimes you only want to react to the value change event and not reset the value back until later 2) Because if reading the terminal and reading the even both set the value back, sometimes the terminal would get read first and then you'd have a value change event already in the queue for a value that isn't the new value. 3) Because the event structure follows the same rules as reading the Value property or reading a local variable -- the only thing that unlatches is reading the FP terminal.

QUOTE (Michael_Aivaliotis @ Apr 29 2008, 12:12 AM) I do. On every Windows app *except* LV it works just fine. Ctrl+insert, shift+insert and shift+delete. Very fast shortcut keys.

QUOTE (BrokenArrow @ Apr 29 2008, 10:27 AM) The behavior hasn't changed in many years. If the FP is in memory, the ctrls/indicators will update, otherwise they will not update. That much I know is true all the way back to 5.1 and before. In 8.5, the FP is in memory if a) the window is open b) there's an open control reference to a control on the FP c) there's any implicitly linked property/invoke nodes on the diagram tied to controls on the FP d) the FP is configured in such a way that LV assumes you want to show it, such as setting a VI for dialog appearance or e) the VI has unsaved changes. There may be some other edge cases (the FP of the facade VI of an XControl is always loaded, for example) but those are the main ones. I think the big reasons go as far back as we have VI Server.

QUOTE (brianafischer @ Apr 28 2008, 05:59 PM) Pretty much. But if you popup on the string control and enable "Update Value While Typing", you'll get a Value Change event each time the user types a character -- including Key Repeat events -- so you can filter or accept as much as you want. At that point, you probably will probably want to know when the user commits the value, so you'll monitor for Key Down on the Enter key and/or the loss of focus on the control (there's some post some where on LAVA about monitoring for loss of control for exactly this scenario... search around for a while and see what you find).

QUOTE (Tim_S @ Apr 28 2008, 04:43 PM) Hm... if you take out the boolean LED and instead put in a round picture ring, you could have a tri-state display. The booleans would use states 0 and 1, and then you could have a third state that is the little red ball that bounces along through the text in time with the music... And if you built the whole thing in LV Real Time, we could make sure that it moves with the rhythm. And then we could have it use hardware to control an actual LED array, built next to some major highway somewhere, and then, we could just post the URL to the Google Street View of that billboard to the to the programming language website that started this whole thing!!!

QUOTE (neB @ Apr 24 2008, 07:21 AM) How about just showing off LV's UI integration? Zero case structures, and the only subVI is "Trim Whitespace.vi". :-)Download File:post-5877-1209146216.vi

Filed as two separate CARs. CAR# 105508 and CAR# 105509

QUOTE (rolfk @ Apr 25 2008, 12:36 AM) All structure nodes provide an opportunity for threads to yield. That bit of yield is all that is necessary to give the Open VI a chance to finish registering the new VI.

QUOTE (crelf @ Apr 24 2008, 03:35 PM) No, you uncultured Austrailian! It's a reference to MONSTER TRUCK SUNDAY!!! When do monster truck competitions happen? SUNDAY SUNDAY SUNDAY! And you would know this if you watched television commercials in the United States any time during the 1980s or 1990s. Nowadays, of course, they happen every day of the week. What are these competitions? Why are they so compelling? Watch/Read the following links and worry that this all comes from a country that has the world's largest nuclear arsenal... http://www.gluck.net/jesus/[/url] http://seattlest.com/2006/01/17/sunday_sunday_sunday.php

I'll offer my support for the UML design aspects of GOOP Developer Suite. If you're trying for large-scale, state-of-the-art software design, you need a way to blueprint your design and ensure that your code follows that blueprint. The UML tool gives you this power. Imagine a VI Hierarchy window where you can just draw connections between little icons, then hit a button and have the VIs all be generated for you. That's the idea, but on a broader scale -- generating classes, VIs, icons, etc, to ensure that your application actually is the one you planned it to be. Sure, you still have to fill in the details for each VI's behavior, but you know which VIs call which subVIs and you don't have to take time managing each individual file's creation. The tool can also analyze an existing class hierarchy and generate the UML from that, which will help you when you walk into a foreign, undocumented tangle of VIs to learn what connects to what. It is easy to use, with very smooth graphics and a straightforward user interface. National Instruments recommends the GOOP Developer Suite for any LV developer who needs UML documentation for their projects. GOOP Developer Suite also includes the GOOP Toolkit to create and manage by-reference classes. Anyone who is a long-time LAVA reader knows my thoughts about references. Try not to use them. Then, when that fails, use them sparingly. If you must use references (and there are some rare times when it is necessary), this is a fine tool for managing them.

QUOTE (shoneill @ Apr 24 2008, 03:12 AM) It is logically impossible to have true abstract classes in LabVIEW. Every VI is independently runnable, and this provides a major advantage during development and testing. But in order to run parent methods, we must be able to instantiate parent data. And every parent control must have a default value. Again, this requires instantiating the parent data. The LVClasses team has been over and over this problem, banging our heads against it. HAVING SAID THAT... it is perfectly legit to have a class that you treat as abstract, not ever actually using anywhere in your top-level VI. And there is a new feature in the next version of LV that will address one key aspect of abstract classes. But that's all I'm going to say about it for now. QUOTE (eaolson @ Apr 24 2008, 10:11 AM) So it sounds like, if primitives inheritied from Object, that would eliminate this problem? (Hint, hint.) Or even wrapper classes around the primitives, with autoboxing/unboxing. It sounds like, if customers would just let me break binary compatibility and not load any existing VIs, this would be easy to implement. (Hint Hint) Unfortunately, it is a non-trivial challenge given 20 years of history, especially since classes aren't yet on all of the platforms that LV supports. It would be hard to tell FPGA "sorry, integers are classes now, so you can't use them". So all platform support for classes has to be a higher priority. In the words of the Wicked Witch of the West from Oz: "These things must be done dellllllllicately, or you hurt the spell!"

QUOTE (eaolson @ Apr 23 2008, 10:26 AM) If you have the right class hierarchy, the strong typing isn't a problem. Remember, in LV, a child class can travel on a parent class' wire. As long as all the information that you're streaming is classes, you wouldn't have difficulties. The hard part would be streaming the built-in data types (numeric, string, path, cluster, waveform, timestamp etc) -- those would either need to be wrapped in a class or handled by Variant, with all the overhead you were noting.

QUOTE (SPM @ Apr 23 2008, 09:18 AM) No progress on the patterns document since August. I typically have time to update these sorts of side projects in the space roughly two months before a LabVIEW release (because LV is done about that far in advance to allow toolkits and manufacturing time before the release). August was when LV released last, and when it actually releases, my attention has to turn back to the next rev. I suppose this means if you see me update this document, you can bet a LV release is coming up. Perhaps I'll have to delay posting new drafts to avoid "early announcing"... :-) As for Bridge pattern in particular: This is a pattern that you can pretty much use as is from the Gang of Four book directly in LabVIEW. There's no special behavior or alternate implementation required. It is extremely similar to the Delegation pattern which is covered in the LabVIEW design patterns document.

As much as I appreciate the queue version, it's a bit complex. And I would point out that percent codes are confusing and string formatting is slow. I'd offer this version, which uses string subsets and string concatenation... Note that I could avoid the Trim Whitespace if I used a case structure instead of a decision node, but I thought being able to see all the frames was more important.

QUOTE (Eugen Graf @ Apr 22 2008, 03:09 AM) 90% of the time you shouldn't care. But if you need to care, look at the terminal conpane of the VI. If the class input has a dotted line around it, that's a dynamic dispatch VI. QUOTE 2) Can I change a static member VI to dynamical and back after definition? Sure. Popup on the conpane terminal, select "This terminal is..." and choose the one you want. QUOTE Should I always take better dynamical? No. You should choose the one that matches your functionality. There are trade-offs to both options. QUOTE 3) Can I use one dynamical member VI on more than one loop in my programm parallely (for copies of the same class) or it's the same as staticaly use in this issue? Reentrant VI is other thing as statical or dynamical member VI? Reentrancy is supported for dynamic dispatch VIs in LV8.5, but not LV8.2.

QUOTE (Eugen Graf @ Apr 21 2008, 09:13 AM) You can't have the class cluster be a typedef directly (for a long list of hotly debated reasons during the design phase of LVClasses that I'm not going into now). But you can put a cluster inside the main cluster and typedef that. Doing so would also save you from ever having to update the Bundle/Unbundle nodes, since you'd just unbundle the cluster as a whole and bundle the cluster as a whole, not each individual element. I'll let someone else field the static/dynamic dispatch question.

QUOTE (PaulG. @ Apr 21 2008, 08:53 AM) Your momma was Hitler! (http://en.wikipedia.org/wiki/Godwin%27s_law' rel='nofollow' target="_blank">Canonical end of thread!)

If MAX is your maximum desired value, MIN is your minimum desired value, and RAND is a random number between 0 and 1 then: RAND * (MAX - MIN) + MIN is a random number in the desired range.

Prober: Please cut the others a bit of slack -- most of the users of LV have never programmed in any other programming language. You'll find a lot of these guys are particularly brilliant if you need help solving a problem with LV, but sometimes the parlance of programmers in other languages doesn't translate directly. There are a lot of conversational conventions used among those of us who started off in BASIC, Pascal and C that aren't shared by those who start off in LabVIEW. That's something that LabVIEW marketing frequently brags about -- the top LV programmers are scientists and engineers who have never had any formal CS training: the language is that easy to learn. In this particular instance, you asked for a DOS app. This translates to a LV user as "can I build an EXE that I can launch from the command line". What you intended it to translate as is "can I write a VI that reads from the command line and writes back to the command line". I hope everyone on both sides can forgive each other. When you're not speaking the same language but you think that you are, it's easy to believe the other side must be completely stupid. Let me assure everyone: Prober wasn't asking a dumb question, and the others weren't trying to be ambiguous. And now, if you'll excuse me, irony of ironies, I have to get back to writing a report for LV marketing on "how to talk about LV when you're talking to computer scientists". There have been some problems with this. :-)

QUOTE (Yen @ Apr 20 2008, 02:15 PM) On dynamic dispatch subVIs, it only works for the dynamic input and dynamic outputs. On static dispatch subVIs, it works for all LVClass inputs and outputs. The reason for the limits on the dynamic dispatch subVIs is that a whole batch of subVIs can be invoked, and we can't guarantee that every subVI that could possibly be invoked will preserve the runtime data type (remember that LVClasses assume that at any moment you could load another child class into memory even while the VIs are already running). The static dispatch subVIs will make outputs match the inputs as close as possible. In fact, if an output depends upon two inputs, the output will become the nearest common ancestor to the two inputs.

G'evening, prober. I understand the questions you're asking... they're the same ones that I had when I first encountered LabVIEW. LabVIEW is a programming language. Like JAVA or C#, there is a runtime engine that is required for any LV program to execute. That LV engine includes two major components: the execution system and the library of built-in routines. Every LV program is compiled to assembly for the native platform. Many nodes in a LV diagram become direct assembly instructions. Others become just enough assembly to call into the runtime engine -- those are the built-in functions that I mentioned. The execution system is the thread scheduler that provides the parallel scheduling of LabVIEW code and handles the spawning and directing of the operating system threads (the optimal parallelization of code in the compiler is one of the major strengths of LabVIEW compared to other programming languages; details on this topic can be found elsewhere on LAVA and ni.com; I'm not going to delve into them here). The native compilers for LabVIEW include the desktop environments of Windows, Mac, and Linux. These are the platforms on which LV code can be developed. Native compilers also exist for the so-called "target platforms", including PDA, VXWorks, Pharlap and FPGA. These are platforms that do not have a LV development environment, but the LV development environment can be told to compile for these targets. Each of these is a module that you purchase separately from the basic LV package. The FPGA module is another major differentiator of LV compared to other programming languages -- our compiler goes directly from the LV diagrams to VHDL to FPGA fabric without further programmer intervention. And the parallel nature of LV code means that when we hit FPGA targets, we get complete indepenent execution of parallel sections of code. Quite cool, IMHO. LV is predicated on a graphical environment. It simply doesn't run without the assumption of at least one top-level application window. So you can invoke a LV exe from a command line, and you can pass it command line arguments, and you can direct output back to the command shell (with difficulty -- it isn't a first-level use case for LabVIEW), but you're going to get a window that opens up while the app is running. You can invoke commands to hide that window, but closing the window will terminate the app. You can write plenty of command line apps using LV, so long as you don't mind that window flickering. Please forgive user tcplomp -- he was trying to make a point about the display capacities of LV, and I don't think he took "dos app" to be one executable in a pipe/redirect sequence, which is I believe what you're asking about. That's where most programming languages start, but, as I said, that's not a first-level use case for LV. LV starts off assuming a graphics interface and only worries about the command line as a very late afterthought.

QUOTE (shoneill @ Apr 15 2008, 01:34 PM) Ah... It is so nice to know that we have reached the point where I can go on vacation and count on others to preach the gospel while I'm gone. :-)

QUOTE (Dirk J. @ Apr 18 2008, 07:08 AM) You only need one VI for all your child classes. What you want to do is create a single VI on your parent class that has two inputs and two outputs, all of which are of the Parent type. And then... oh, heck. Instead of typing this out, I'm just writing the VIs. Here you go... Open the project and then look at "Demo.vi"... Download File

Check your upgrade notes. You'll note that there's all sorts of comments about the internal version number having not been bumped. You should also be aware of this.