Leaderboard

LapDog Message Library v1.2.0 has been released and is available on SourceForge. It packages several classes designed to simplify general purpose messaging for object-oriented programmers. Highlights include: 1. Familiar methods! If you've used a native queue and you're comfortable with LVOOP, you'll have no trouble figuring this out. 2. More convenience! Have you ever overloaded your Default case with error handling, timeout handling, and more? No more! DequeueMessage (and PreviewMessage) checks for errors on the input, errors from the dequeue prim, and dequeue timeout conditions, and returns unique messages for each of those conditions. Say goodbye to the hassle of nested case structures just to handle normal checking procedures. 3. A PriorityQueue! Ever wish you could easily prioritize messages in your queue? The LapDog Message Library includes a class that does just that. Better yet, it allows you to configure the number of priority levels your queue will have. 4. A collection of message classes for native Labview data types to speed up your development. Includes classes to support the following native types: Error Cluster, String, I32, Boolean, Path, and LVObject. If you need something not included, it's a snap to create your own class that inherits from Message.lvclass. 5. Palettes, cool looking wires, and more! The LapDog Message Library requires VIPM Community Edition (or better) to install. The package currently requires Labview 2010; however, we hope to release a version for Labview 2009 soon.

As ned has already explained quite clear you have to use LabVIEW memory manager functions if you want to hand data back to LabVIEW directly. The GetValueByPointer XNode is just a way to deal with native pointers, when you have no way or don't want to modify the DLL itself to deal with LabVIEW handles directly. What it does is copying the data in the pointer into a LabVIEW handle. And if you don't clean up that pointer yourself afterwards it will be leaked. Nothing LabVIEW can do about, since the DLL interface is simply a function interface with no defined conventions about how to allocate and manage memory across that boundery. DLL x could use a standard malloc function for that while DLL Y comes with its own memory manager implementation and LabVIEW has no way of knowing about this at all. Why LabVIEW uses handles? Because traditionally that was required on older platforms to have efficient variable sized memory structures (strings and arrays) and changing that now is no option at all. Even if it would use pointers the fact that the caller never can know what the callee used to create a particular memory block and vice versa, would still prevent fiddling with pointers created in the other component.

In those examples, the data returned is always a pointer-sized integer, which is then dereferenced by a mysterious XNode call GetValueByPointer. The example provides what I assume is equivalent LabVIEW code for dereferencing a pointer using MoveBlock. Dereferencing the pointer this way copies the data from space allocated by the DLL into space allocated by LabVIEW. I'm guessing that in your case you are trying to return the structure/array directly by reference, allowing the call library node to handle the dereferencing. As a result, you're handing LabVIEW a block of memory that it didn't allocate, so it doesn't know how to manage it nor free it on exit. I'm not sure what happens to the memory allocated by the DLL in the examples; I'd guess this would be a memory leak if called repeatedly, and that the operating system would clean it up on exit, but that's mostly a guess.

If you're going to allocate memory in your DLL and then hand it back to LabVIEW, you should either use the LabVIEW memory manager functions, or allocate the memory in LabVIEW and then pass pointers to it into your DLL. The LabVIEW memory manager functions are documented in the help, under Code Interface Node functions. Alternately, you can initialize the memory in LabVIEW before calling the DLL by using Initialize Array; for a string, initialize an array of U8 and convert it to a string.

I would say a truly decoupled UI would be one driven by an API that is not limited to LabVIEW. In other words, using something like Web Services, you could build your UI in LabVIEW or HTML or C++ or any other language and interface to the underlying engine via calls. There are other options to this of course. I think a good first start would be to separate the UI code from the engine code so your low level logic does not access any GUI elements. This could be done by using queues, events or other messages to communicate state changes and user actions between the UI code and the engine. Next, you need to ask yourself what the physical channel will be between the two. If you will be on the same machine in the same app instance, then you can use queues and events. If you plan to be across the network, then some other method will be needed (web services, raw TCP/IP, network streams, share variables) and if your UI is not going to be LabVIEW, then you narrow yourself to web services or something like web sockets (http://www.bergmans.com/downloads.html). Overall, decoupling now can allow you to pursue these options down the road more easily. Lastly, you need to consider if you will build a client server model where multiple UIs can interact with a singe engine simultaneously. That is a harder nut to crack...

Thanks for the kind words Felix. I showed your post to my wife and she said, "I like this Felix guy." I thought maybe it was because of the nice compliment. Silly me. It's because you have Johnny Depp as an avatar.

Here is a demo vi in LabVIEW 8.2.1