Aristos Queue

No, it's not on the Exchange, but kudosing it there won't accelerate its development. We've already bought into needing it, it's just a question of getting it done. It's on the priority list already.

Feature not yet implemented. Hope for LV2010, maybe 2011.

On the front panel, set your ring to the desired initial value and then popup and select "Data Operations >> Make Current Value Default". Now it will have the selected value as the default value.

Regarding benchmarks, one of the FPGA team passed along this tidbit: You can compile FPGA VIs on a computer that is not attached to any LabVIEW FPGA targets, which lets you see the resource utilization and whether the code met timing constraints. In other words, you can do a reasonable deal of benchmarking without access to the hardware; you do need to have LabVIEW FPGA and NI-RIO installed to compile for a cRIO system.

Or, more simply, just get an *unnamed* ref and put that into the into the class global, rather than the name. Now any member of the class can get the SEQ refnum from the global, without having to create and manage a refnum themselves, and there is no way for anyone outside of the class to get the reference, no matter how much guessing of names that they try.

Sorry -- I include the parent cluster in the size of the child... that's me having too much knowledge of what goes on behind the scenes. ;-)Dynamic dispatching is entirely folded out in the compiler -- if we cannot resolve it to a static dispatch at compile time, the VI returns a compile error.

I can't point to any examples, but the code generated is identical to a cluster of the same size as your class.

If you want write-once-read-only-thereafter, you *don't* want a global VI. My suggestion of the global VI as class static data [aka data common to all instances] is specifically for the cases where it would be modified from time to time. The list of methods of any given class should be trivially short enough to confirm that none of them is abusing the global VI, something not possible with a truly open global VI. If you want a "set once and read only thereafter", just write an LV2-style global with the First Call primitive. That's trivially done in LV today. Here's an example: The input terminals are Recommended, not Required.

First Call primitive can take care of that... just put all the code in a case structure that only executes if First Call is true. Thus even if multiple calls are made, the later calls are ignored. Does that solve the problem?

Why would you create useless event references? You shouldn't actually create the event reference until someone calls the property to get the reference. You do the creation in "UserEventReference Read.vi" on demand, not when it is constructed. You can have a single event that the facade knows how to process that is "add this event reference to the references my event structure is already registered for" that you fire the first time someone calls the property read to create the event. Your facade VI processes this meta-event to add to the array of registered references.

Your comments reminded me of a about a use of global VIs that might redeem them in the eyes of many LV programmers. I've been meaning to start the discussion, and your post here got me to do so. I posted the topic here.

A topic that has never come up on LAVA or in any of the presentations/discussions I've been involved in in the last three years: There is a general repudiation of global VIs among advanced LV programmers. Generally, globals are good until the first time you are sorely burned by them, and then you develop an allergy to them that gets stronger with time, especially as you discover techniques that give you other ways to share data in your programs. The argument against globals is They allow any random VI any where in your system to change values, making it hard to write stable, proveably-correct code. They always create a data copy on read. They are subject to the read-modify-write race condition if used in two places in your code in parallel. But the argument from the other side is that global VIs are so easy to write compared to [insert alternate mechanism here] You can search and find all uses of a global VI, which you cannot do with Data Value Reference (DVR) and single-element queues (1EQ). You can search for all uses of LV2-style globals (LV2), but most of the time, those are written with a simple get/set, which means they have the same data copy and read-modify-write danger. So why not just use a global VI? The argument is one for the ages. But now we have LV classes, or any library, really. With a library, we can create a global VI and make it private scope. Now we know that the global VI is only used by a finite set of VIs -- those that are members of the class. We can guarantee that any read-modify-writes are either done singly or can be guarded by semaphore locks. We can combine the global VI with a DVR, so that the global VI stores the refnum of the DVR for easy lookup, and let the DVR be used to avoid the data copies. The original presentation of LVClasses mentioned the use of global VIs as a good way to implement data common to all objects of a class (called class static data by C++/C#/Java programmers). But the question of whether this is a good recommendation has never come up. Given all of this, I now formally ask the question: should a global VI that is given private (or community, since the same finite-set-of-VI-arguments apply) scope be considered acceptable LV coding practice? Would a VI hierarchy that used globals in that way be acceptable in the LAVA Code Repository?

None that aren't proprietary. But the effect is something we see commonly: an object that is essentially nothing more than a cluster, like, perhaps, a block of configuration data for some hardware, is passed around as a reference, being looked up from the ref each time a node needs data from that cluster instead of wiring the cluster through to all the subVIs by value.

This is a recorded webcast from Trevor Christman, a member of LV R&D on the Language Team with me. In this webcast, Trevor lays out the basic ideas behind OOP, explains how these are implemented in LabVIEW, and shows off parts of the LabVIEW user interface. This is an excellent presentation, and may help those of you who don't enjoy reading documentation learn the power of LVOOP. I fielded questions during the presentation, which you can see scrolling past in the chat window. http://zone.ni.com/w...oc/p/id/wv-1766 [EDIT] There is a sequel presentation now: http://zone.ni.com/wv/app/doc/p/id/wv-2003

Ah, come on... admit it... you folks would be bored out of your minds if we didn't include at least a few bugs for you to work around... ;-)

New Parents: In between changing diapers and cleaning burp rags, take a moment to consider your child's future. Will your little one be able to make it in the rough and tumble world of the future? Yes, but only if you provide the right tools. And what could be more important to your child's future than LabVIEW? Sure, you could make a couple extra house payments, but will that help your child's education? No. Good parents know that a child's work prospects depend on a fully licensed copy of LabVIEW. You can help them out tomorrow by your actions today! Just start sending annual checks in the amount of $3000 every year to "National Instruments." We'll hold onto those funds for you and when your child is old enough to need their own block diagrams, you'll have built up a tidy nest egg, which NI will generously apply to the annual Software Subscription Package. If you make this easy payment of just $250 each month, by the time your child is 18, you'll likely have enough saved for them to have six or even seven years of LabVIEW enjoyment*, more than enough time for them to establish themselves in the industry. Act now, and you can also establish separate trust funds for your child's TestStand, Diadem and MeasurementStudio! Why would you wait? Even while you think about the value of this offer, your child is getting older. Start sending those checks today!* * accounting for likely increases in SSP cost ** This message not endorsed by NI, its affiliates or my managers *** Congratulations, Jim!

I on the other hand would not even consider a reference solution unless all else failed. My solution: Give your ListOfPigs class a method called UpdateOnePig, which takes an index of a pig and instructions on what to do to that pig. The instructions can come in the form of parameters that you pass into the ListOfPigs' VI or a VI Reference that you call. The block diagram of the UpdateOnePig has an InplaceElementStructure that has an Index and Replace array node on it.

If you change the inplaceness of a subVI, the caller VI will be broken when it loads. The caller VI checks that subVIs have the expected inplaceness and breaks unless it matches the inplaceness the caller was compiled to expect.

Excellent strategy. This isn't formally documented as a pattern but probably should be.

I think for detecting Is Sibling you're going to have to add framework VIs. I can't think of any way to do what you're asking with built-in functionality.

I'm so proud of the little Equals prim. You know, I taught it everything it knows. ;-)

Yes. Here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Insert-class-VI-contextual-menu/idi-p/996055#A2548

Write a static dispatch VI -- it does NOT have to be a member of the class, assuming the dyn disp VI you're trying to invoke is public -- that has the same conpane as the dynamic dispatch VI except that the terminals aren't dynamic. Have the static dispatch VI call the dynamic and then use OpenVIRef to open ref to the static dispatch VI.

The recovery system autosaves every 5 minutes.

Everything counts in large amounts...