Terry,
There are two issues here.
First of all, when you use "Get this VIs Path" in development, you get a different answer than you do in runtime. This is because the VI no longer has a path.
Secondly, when you build the application, VIs called by VI server do not become a part of the application. They remain as VIs, but are included, if you choose, in a directory that you specify, or are not included at all.
My company uses a utility (that I created) that solves this issue. However; you have to be careful about implementation. The utility is quite simple: It stores the location of the function itself when it is a VI, and the location of the dll when it is deployed. You can very easily change this function to search for an exe.
As this
code belongs to my company, I cannot post it. However, I can help you create one if you like. Again, it is quite simple.
Here are the instructions for you to create your own. I have written it in pseudocode.
"Get This VIs Path"
Strip Path
Convert Path to String
Search String for "[.]exe" or "[.]dll" if it is a dll
if Offset Past Match of Search String <=0, output stripped path
else, strip path again and output
You have to remember that for development, you have to place the 'slave' VI in the same directory as the utility that gets the path. This is VERY important: YOU MUST BUILD A VI THAT GETS THE PATH. In otherwords, the code above must be a seperate VI, that you drop in to replace "Get This VIs Path". You then have to remember that the path is the same as the location of the utility that you built. When you build the application, the slave VI has to be in the same directory as the .exe for this to work properly.
The ONLY other way around this is to hard code
the file path.
I hope this helps