Running a VI by reference inside a DLL

[Jeramy_Soucy]

I am building a DLL in LabView.  In one of the DLL VI's, a VI must be called via an invoke node in order to ensure that the calling VI does not wait for the called VI to finish execution (essentially spawning a thread in LabView).  How is this done?  How do I format the path to the called VI?

[JLS]

Hello,

I see that this thread has been live for some time now; sorry you didn't get a quicker response!

Anyway, all you have to do is make sure that the path to the VI you would like to run using the invoke node is specified correctly.  You have a couple standard options:

1. Have a string input to that function in the dll so that you can pass the path to the VI that you'd like (in the VI which will be built into the dll, you can use the string to path conversion function to convert your string to a path to use as input to the Open VI Reference function).  This way you can simply pass the dll your desired path.

2. Hardcode the path in the dll - this has the disadvantage of requiring that your VI be in that hardcoded location.  A more flexible variation of this method is to use the "Current VIs Path" function found in the File Constants subpalette of the File I/O palette (see the attached screenshot for a picture of this).  You can then strip off the current applications name and use the base path to build the path to the VI you want to open programmatically (see the File I/O palette for the build and strip path functions as well).  This way all you have to do is make sure the VI you want to run is always at some location RELATIVE to a known path.  Although it's still basically hardcoded, the path is determined dynamically and makes it easier to port to other machines.  Option 1. is probably the easiest, most flexible way to go if you can use it!

Hope this helps!

Best Regards,

JLS

[Jeramy_Soucy]

Thanks for the reply.
I figured it out later the day I posted the message.  I should've responded to my own thread once I had the solution, but I had gotten caught up in my programming.

I ran into another interesting issue so just in case anyone viewing this thread ever wants to know...

You can get seemingly random crashes and memory errors in labview when using C-style strings in DLLs if you are not passing an allocated labview string into the DLL call for the string parameter.  For example: I have a DLL function with an output parameter that passes back a status string (using C-Style strings...unlike labview's pascal-improved style).  If you call this DLL in labview, you must pass it a string that contains x number of characters, where x is the string buffer size you wish to use.  When you think about this from a C point-of-view it makes sense.  First you must assume that LabView does NOT allocate any of its output parameters when using C-sytle strings in DLLs.  From there you must assume that LabView deep-copies the internal string into the one passed in...in which case the parameter must be allocated to some size.  The crashes occured "seemingly randomly" because LabView was copying string data to a garbage memory address that was being passed in...sometimes this would work alright when the memory happened to be free, but other times the memory was already in use and a crash or memory error would occur, corrupting the labview memory space.  I would suggest writing a utility VI/function to include in the DLL or in a string library that takes in a numerical value for the desired length of a string, and outputs an allocated string of that size.  With this utility VI you can easily allocate string buffers to use for catching DLL string outputs.

~ JS

[JLS]

Great!

And thanks for the rest of the post too!

Best Regards,

JLS