Leaderboard

Speaking as the guy who wrote the queue primitives... The queues are meant to be the primary means of communicating data in LabVIEW between parallel chunks of code. They are completely thread safe, and they participate with LabVIEW's concurrency scheduling algorithms. They're designed to minimize both data copies and latency and have been stable for many years. User events go through queues that share most of the code with the general queues, although they have a bit more overhead since at any time there might be multiple listeners for an event, which can (not necessarily "will", just "can") cause more data copies. User events are data broadcasters, where as general queues are data point-to-point transmitters. The general queues thus have less overhead, but it is a very small amount less overhead. For me personally, I prefer the general queues instead of the user events only because of the arcane nodes and special terminals that are required to register dynamic user events. I use user events when I need to have code that sleeps on both UI events and data arrival. But it is really personal preference -- many programmers are successful using user events generally.

The pi is imaginary!

If it is listed in the project or is used by any open VI then it is already loaded. It's not a version problem -- that's a separate error code. This error only occurs when the data was flattened with a class of name XYZ and when unflattening there is no class of name XYZ in memory. I don't know (or at least don't recall) the bug that Jarrod S mentioned. As far as I know, that's the only situation you should be getting this error. Look at the actual flattened string... you should be able to see the name of the class embedded in the binary string. Look at the Class Hierarchy window. Is that class in memory?

Usually, this happens when you have a Child class being flattened on the RT system and on the host system, you unflatten it as a Parent class, without the child class actually being loaded on the host side.

I have seen this error happen before for classes that belonged to a LV library. They would fail to be unflattened with this error even though the class was indeed in memory. I believe this bug was fixed in LV2009.

Don't forget to check out this tabbed x-control beauty by Olivier Jourdan too.

A while back I asked if anybody know how to sort the event structures by using scripting, and unfortunately that couldn't be done by scripting yet. So the other day when I held my weekly LabVIEW meeting, I went through how this could be done. Here is the solution: Here is a prototype RCF plugin. SortEventStructure2.zip Cheers, Mikael