Aristos Queue

Nah... that one just helps you stop smoking. :-)

After I finished crying, I added an autotest to LV's nightly test suite just to make sure if anyone did try to change the private fields of those two classes in a way that they no longer coincidentally lined up, we'd see the crash on our end long before release. So far, so good. No one has felt the need to refactor strings. I still don't recommend it, which is why I was waiting to see if the "copy a constant with the right font" workaround would suffice before mentioning this dark alchemy. :-)

Why are you still using VITs for dynamic instantiation of VIs? Of course its slow! Instantiating a new VI from VIT creates a wholly independent copy of *the entire VI*. Contrast this with creating a new clone of a reentrant VI, where we only clone the dataspace and the front panel if and only if its open. We never clone the block diagram, just draw it in two separate windows. Replicating VITs was a practice that should have largely stopped in LV 8.0 unless you are scripting new VIs as part of an actual "create me a brand new VI in the editor" tool. There are some edge cases when you're actually scripting new controls, but most UIs don't use that approach because it only works in the full dev environment, not the runtime environment. So for UI work, stick with reentrant clones. This is why going from .VIT to .VI has an impact -- instead of copying the VIT to create a new VI, you're just cloning the reentrant VI.

Has anyone ever given any thought to the LAVA community creating one single patch for the LabVIEW development environment? In other words, LabVIEW ships from National Instruments and then after installing LabVIEW, a user would then install the Community Patch. What would/could the patch do? 1. Install any number of useful tools in one go: right click framework, quick drop short cuts 2. Add useful OpenG tools 3. Update the configuration file to set settings different from the defaults that LV offers 4. Change the default custom probes 5. Fix bugs that the community has prioritized There are fewer developers here at National Instruments than exist in the wider LV community, and so it is not surprising that there are many great tools developed by members of the community that significantly improve the LabVIEW user experience. Identifying all the tools that I'd like to pull down and install -- or that I would recommend another user pull down and install -- is hard. Some of them are available as packages, but many others are just one-off VIs posted to a forum, like an improved custom probe. I might read the post one day, think, "Great! Let me grab that." So I copy it into my current version of LV. But I don't remember to copy it into LV on my other computers, and when it comes time to upgrade, I may not remember to copy that VI into the upgrade. Ideally such things would be flowing back to National Instruments and we in LV R&D would be over time adding them to LabVIEW's own installer. But there are often licensing problems with us picking up VIs from forums, and even when there aren't, the other priorities required to get a release ready often trump pulling such tidbits in. That got me thinking... Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience." That makes it easy for a user to just install one thing and get a set of reviewed improvements all at once. I suspect a lot of tools that otherwise languish in the hands of a few expert users would suddenly have a much wider adoption, and a lot of forgotten niceties would enjoy a renewal. Plus it would give LV R&D one package to review each release, instead of relying on someone happening to have tripped over an interesting post in the forums, which might help get these tools into LabVIEW's own installer. I have no idea if this has been thought about before, no idea how workable this would be, but it doesn't necessarily have to be all that organized. A lone developer deciding to maintain such a package and add to it whenever he/she saw something interesting on the forums would be valuable. An ad hoc group might form around him/her to advise on "posts that should go into <Your Name Here>'s LV Patch". Thoughts?

Unfortunately, not everything you can do in the editor has been exposed through scripting, and this is one of the holes. Depending upon what you're trying to script, it might work to have a template VI that has a constant on it that already has the font style you want... instead of creating a new constant and trying to set the font, copy the constant from your template and just set the value. Obviously that won't work if you're trying to set an arbitrary font, but if you have a specific font you want to be able to do, it works.

I still can't get them to stop, and I work there. I get occasional offers to purchase LabVIEW or take a training course if I go look something up for a user. :-)

"Everyone expects it, so this year, we'll prank them really good... we won't have one!" "Yeah, that'll really wind them up for 2013!"

We changed the EXE format specifically to deal with the "multiple VIs have the same file name" issue. Turn the compatibility mode off, fix your paths, and then the system should start working for you. One function you need to know about is "Application Directory" -- it's a node in the palettes. In the development environment, this is the same directory as your project (assuming you're in one) and in the built-EXE, this is the same as your EXE. This makes writing dynamic load code a lot easier. If you want to dynamically load VIs that are part of your EXE, just calculate them as relative paths from your top-level VI. The same relative paths will be maintained inside the EXE as you have before you build the EXE.

I realize this is an old thread, but I was pointed toward it as a reason people should avoid Value(Signaling). So, since I am AQ :-), I will pipe up and say: Yes, the order of receiving is guaranteed to be the order of firing. The events use the same queues under the hood as the Queue functions. When you fire from parallel threads, the order isn't known any more than the order of two Enqueues in parallel would be known. But if you fire events serially, it's the same as if you had two Enqueue nodes in order: they go into the event queue in order, and, like all LV queues, they come out in the same order. There are plenty of parts of Events that I don't know, as it isn't my feature, but I know well the part of events that interacts with the queues. :-) And, for the record, in this thread you'll find my argument for circumstances when I would use Value(Signaling). I won't say it is wide open, but I believe there are legitimate, even recommended, uses for it.

A friend pointed me to a website dedicated to restoring rare words to common usage. The site randomly picks a word for each visitor to popularize. I got two, and both of them are excellent choices for me since I have a use for both of them. The one that I encourage LabVIEW users to adopt is: primifluous: that which flows first. As in: "The primifluous wines were excellent." For LabVIEW and dataflow, the usage is obvious: "The primifluous nodes initialize the hardware." "Perhaps you should make that assertion primifluous.""FP Terminals are primifluous unless placed inside a structure node." (The other word, in case you're interested, is "nidifice", and older term for an eagle's nest. Pronounced with "nigh" at the beginning and rhymes with "edifice". Given that NI's mascot is Nigel the Eagle, and that this term begins with "ni", I will henceforth refer to NI headquarters building as The Nidifice.)

I posted List and Tree a while back: http://lavag.org/top...classes-for-85/ It becomes unstable around 1000 elements because it relies upon recursion. The DVR solution is much more complex and has the weirdness involved with references, but can go much deeper. Note that a list of 1000 elements is pretty poor... but a tree of depth 1000 is 2^1000 elements, which should be more than enough. :-)

Neil: that's exactly what I would suggest -- with the option to replace "user event" with other com techs such as queues or notifiers, as needed in your code. Actor Framework would just make both the outer host VI and the inner subpanel VI be actors and then communicate the stop message through the queues.

I prefer to just disable the X using the VI Properties... less code on diagram to have to worry about. And the user doesn't have a useless [X] button to keep clicking on that doesn't do anything. Unless, of course, you're going to actually add code so that the [X] button causes Exit.

The first time this came up, the only thing I replied to was the factual error -- I'm tired of that garbage collector myth being propagated. What I avoided was any commentary on the main post because I didn't feel like it, but today, I feel like asking: Why do your objects have lifetime? Processes (VIs and communications channels) have lifetime. Data does not. These patterns that you're developing in your code come about because of the co-joining of these two concepts, an artifact of other programming languages that are piss poor programming models for a parallel environment.

Never break this rule: If an XControl or its member VIs knows about a class in any way shape or form, then that class must not know anything about the XControl except for (optionally) listing the XControl as a friend. You must avoid creating a circle of load dependencies. The easy way to test this is 1) In an empty project, load the XControl. 2) In a second empty project, load the class. 3) Look at the Dependencies section for both projects. If both projects list the other file as a Dependency, then you have a cycle. Do not use the XControl on the panels of the class member VIs. Do not use property nodes of the XControls on the diagrams of the class member VIs. The only thing that your class *might* want to do is add its XControl as a friend and then put some utility VIs in the community scope. Violations of this rule inevitably lead to a crash of LabVIEW. I'm not proud of that fact. Fixing this crash would require us to design XControls completely differently from the ground up, and it just isn't likely to be fixed. Having said that, the crash does enforce the really good design principle of your data type knowing nothing of its display. So there is, I guess, a silver lining to the crash. Now, assuming you follow that rule, > What should/could I put in B's private data member ? an array of As ? an array of references to As ? An array of As seems most appropriate. References? Who taught you about those? Ick! :-) > What should/could I use as my xControls data type ? The natural answer is the same type as the class I wish to assaciate it with, but somehow I wonder if it can work in this case ? The class. Assuming you follow the rules above, it works great. Build the class completely independent of the display, make it work, then build a display that let's users manipulate it.

It means a LabVIEW developer momentarily forgot that his/her users were not C++ programmers, the tech writer was on vacation, and this was written so long ago that when I asked if we could change it, the answer I got was, "No, that's the label of the terminal, which means someone might be using it in scripting code, and you'll break their code if you change it now." That one doesn't count. That's an IEEE standard definition of the numerical value of Not A Number. That's correct as it stands, not a C++-ism that should have been scrubbed back in the dawn of LabVIEW. At least he's not drinking tonight. "Two beds and a coffee machine..." ** Hah! Take that stupid editor. Try to inline my media files when I don't want you to... grrr...

Good read. I added this link to the Actor Framework community page.

Glad we were helpful.

And thank you for your patience.

Asbo: You miss the point... these are cases where you *don't care* whether the enqueue succeeds or not. Things such as "I am a task that fires this event if there's someone listening... if there's no one listening anymore, I keep doing my work." Literally, you don't want *any* notification if the thing fails. That's almost always the reason that I see "Not A Refnum" included in people's code.

ShaunR: The AE solution doesn't provide any protection against the race condition I originally posted about as long as the refnum is shared anywhere else... you'd have to encapsulate all operations on the refnum within the AE. Because, in general, the whole point of "check if the refnum is valid and only do the operation if it is valid" is from use cases where you don't want an error if the refnum is invalid. So doing the op but ignoring the error gets you that effect.

Austin: Populating the user.lib palette is indeed as simple as saving into the user.lib directory. However, if by "creating a user library" you mean creating a distribution package for sharing your VIs with other people, then jgcode is right: VI Package Manager is your best tool for packaging and distributing a block of VIs... and, yes, there is a free version that does the basics that will probably suffice for you. As for the controls in the palettes... Tools >> Advanced >> Edit Palette Set... That will launch the palette editor. Create a new palette in the front panel palette (by right clicking) and then set it to sync a particular directory on disk. Any controls you save to that directory will be picked up the next time you restart LV.

Nope. It would make it just as likely... the structure node could not hold the lock on the refnum because you're using nodes that need to be able to lock the refnum inside the structure node. Even if you taught the nodes to recognize when they are directly within a structure node AND the refnum they're given is the one that the structure node is locking, it wouldn't help if the nodes were in a subVI inside that structure node.Ultimately, this is the problem with references and is why I push so hard against being able to wire a reference directly to a by value terminal for method invocation. Without a single function that checks "is valid and if so do the operation" atomically, there's a race condition. If I write a by value class that has methods "Is Initialized" and "Do Something", wiring a reference to those two functions in sequence is incorrect usage. Whoever writes the reference API needs to build a single VI that locks the reference once and then does both of those operations before unlocking. These sorts of race conditions become ubiquitous very quickly and they're nearly impossible to debug. Heck... half the time I can't even convince people they have a bug because "it works just fine when I test it." And it will... until you've deployed it on your largest customer's end system. And then it will mysteriously fail. Your time will vary depending upon the type of the refnum. Some types of refnums take longer to validate than others, depending on what system is used for the backing store for that refnum type and, in some cases, how many refnums are in memory. Also, some plug-in type refnums may require calling into a DLL using the UI Thread, so there could be a thread swap. Finally, the "equals not a refnum" test is deterministic, whereas the other test is not.

No. There are some experiments that I have to keep from escaping the lab. No. :-)

Actually, I do expect people to register zero... but zero and unregister are functionally equivalent.