Leaderboard

If I'm understanding you correctly, you want to compile your reuse code into enclosed components which you will dynamically link to both from the IDE and from executable code. Maybe we can call them Dynamic Link Libraries. What's your motivation for doing this? I can see some advantages, but it seems to me that the headaches involved far outweigh the advantages. That said, here's one possible implementation - You could probably use the Get VI Version method to get the version of the VI (although I'm not sure it will work when you run it in the RTE. You might need to save the version in the "DLL" somehow). You will then need to launch a background process with the correct version (RTE) and open and run the VI using VI server. As I said, I think the cons (not least of which are the perfomance issues you'll probably run into) outweigh the pros. As for this: Are you sure they both ran the same version (e.g. the EXE would have its own copy by default unless you explicitly call the VI on disk by ref)? Also, one way you could probably break it is by having incompatible typedefs like Ton said. There are probably others, but these are corner cases. I can't say I personally see the need for running after them. Of course, if you are going to be playing with this stuff, you will want to know what can bite you.

No I think integrating LabVIEW modules as DLL into a LabVIEW application is a fairly roundabout way of doing business. It is possible and even works most of the times, but there are gotchas. 1) The DLL interface really limits the types of parameters you can pass to the module and retrieve back. 2) There is a LabVIEW => C => LabVIEW parameter translation for all non-flat parameters (array and strings) unless you use LabVIEW native datatypes (handles) AND the DLL is in the same version as the caller => Slowing down the call. 3) When the versions don't match there is also a proxy marshalling of all data paramaters necessary, much like what ActiveX does for out of process servers (but it is not the same marshalling mechanism as in ActiveX) since the DLL and the caller really execute in two different processes => Slowing down the call. 4) The DLL can not for the sake of it communicate through other means with the caller but through its parameter interfaces or platform system resources (events, etc). The notifiers, LabVIEW events, semaphores, etc. are (maybe shared and meaningful in the case of same DLL and caller version) but certainly completely useless if the DLL is in a different LabVIEW version than the caller. There are probably a few more gotchas that I haven't thought of at the moment.

"I code in your general direction!"