Leaderboard

If there is only one recipient, do you really need several queues? I could think about one queue which is fed by several senders. If they need different data types, you could use a standard message type for the queue: A cluster, containing an enum ("command") and a variant ("data"). For each command there can be a different type of cluster in the data part. If you use this kind of message queue, I am quite confident that you will soon find out many additional ways to make use of this concept.

Don't use a U16 to hold that a number that large (or it'll wrap around as you're seeing).

I just wanted to inform that after total rewrite of everything (to LVOOP) I reached exactly the same functionality as it was before. That's a progress, isn't it? So now it's time to start extending VIpreVIEW. For the beginning, following Yair's suggestions, I designed a logo: I also attached recently generated swf, as these from previous posts are gone, but I'dont know how to embed it in the post... BBcode is not working. test3.swf Also if someone who got the power could move this topic to uncertified code repository where is much better place for it?

No, I do not think so. First there are no such things like DAQ thread, etc in LabVIEW. There is a DAQ Execution System and some others too, and each of them exists of usually 2, 4, 8 or more threads allocated at startup of LabVIEW. In newer versions the number of threads is even dependant on the number of cores the machine has. LabVIEW simply allocates those threads at startup and the OS provides them but the OS has no idea what they are used for. There is possibly one exemption which would be the UI Execution System with always only one thread and this is the initial thread that was implicitedly created by the OS when the LabVIEW process started up. This thread is priviliged in Windows terms in many ways as it is for instance the thread that is used to dispatch any Windows events to the application and many technologies like DDE, ActiveX and such in Windows rely on this thread being responsive in order to work properly since the synchronization (for RPC for instance for Remote control of ActiveX) is going through the message dispatcher. It's a piece in Windows that is in fact amazing to work and keep working over all the different Windows versions. And I have not seen any methods in LabVIEW that would return more specific information about the different threads such as the Windows Thread ID, which could be used to identify the different threads. Windows itself with the exception of the UI thread and that also only by implication, has no idea about what thread would be assigned to what execution system. Rolf Kalbermatter

There is a novel technique that I have seen and done a variety of times. It requires creating a wrapper for the "Send Notification" VI like this http://screencast.com/t/zRDGaScM What the video hopefully details is that you can create a VI that is in memory on Application A. Inside of that VI is a shift register that holds the reference to the needed thing (semaphore, queue, user event and so on) Then you pass that VI the data that you want to end up in the (semaphore, queue, user event, notifier, and so on) using Call by Reference Node And then the VI fires the (Notifier, user event, EnQueue) with that data and the stored reference. By doing that, you have successfully sent data to any other LV application regardless of whether it is another Application Instance, an executable, or a VI across the world. Note: Scott Menjoulet (LAVA member w/ the Detroit Red Wings Avatar) is the originator behind this idea, and I have merely been it's rah -rah boy over the years and strange uncle to work it into a generic LVOOP based implementation in LVx See the attached file for the VI's and projects used in the video Step 1 is to open both projects, local and remote and then go from there. -Norm REx.zip

Both assumptions are correct, but there is something you can do with respect to assumption #1 depending upon your particular queue.Suppose you have a queue of arrays of 32-bit integers. The queue is filled by 20 arrays each of 100 elements. If you flush the queue, the queue will simply note that its current buffer index is zero and the length is zero, but no elements will actually be deallocated. No help there. But if you flush the queue and then enqueue 20 empty arrays, the bigger arrays in the queue buffer will be deallocated, giving you a bit over 400 bytes of memory back, but the queue buffer itself, 20x(size of pointer [4 bytes on 32 bit machine]), won't be deallocated unless the queue is destroyed.

The Call Library Node does not directly support to pass complex datatypes, resp. it does using the Adapt to Type but this passes an array as a LabVIEW handle which is absolutely not the same as a C array pointer. So you will have to trick this a bit. First configure the parameter as an array of bytes (8-bit integers). Then allocate a byte array of enough length with the Initiliaze Array function and pass this to the Call Library Node. The returned byte array can then be typecasted to a LabVIEW array of clusters and should after that be routed through a Swap Bytes and Swap Words node when you are on Windows. Alternately in LabVIEW 8.2 an newer you can use the Unflatten from String function (convert the byte array first to a string) where you set the endianess input to little endian, or even better native, host order, and the "data includes array or string size? (T)" set to false. With this you replace the Typecast and Swap Bytes and Swap Words. You will have to create a cluster that is compatible. For the char name[32] and char pad[3] you can NOT use a LabVIEW string but must instead insert another cluster of 32 resp. 3 8-bit integers. The get the length of the entire byte array typecast this entire cluster to a string and get the string length and multiply it with the number of struct elements you want to pass to the DLL function and then pass this value to the length input of the Initiliaze Array node. Rolf Kalbermatter

Here's a method that uses a relative path to open a VI reference. The VI reference allows you to manipulate the other VI at run-time. You can execute either VI, but because there is absolutely no communication between the VIs, they don't know which one started first, so both will be visible initially. As soon as you click the switch button, one will hide and the other will stay visible. This is just an example to illustrate the concept for you, you should not just plunk this down into your project and expect things to work spiffy. If you have questions about this method, fire away.

QUOTE (Antoine Châlons @ Dec 18 2008, 04:19 AM) I don't think you can programmatically login. I only looked briefly at the Skype ActiveX interface and it seems if you open a reference to the SkypeClient interface you can define the user to login with in the IClient.OpenAuthorizationDialog method but it has no password so if this is what you are looking for it will simply put up a login dialog to prompt the current user for his password. The IApplication.Connect method doesn't seem better. Rolf Kalbermatter