Thanks for the replies everyone. Here's what I know so far...
"is the LV 7.1.1 RTE installed on both systems?"
Both systems have fully licensed development systems of LV installed. The target system is not in an environment that is conducive to much development activity but work is done there and brought back to the real development machine (hence the reason why I said this happened regardless of the direction of transfer of the VIs - they can get updated on each end and then moved to the other system).
"check the value of the "ProgramFiles" environment variable"
I don't see anything out of place here. The "Path" variable is OK (makes sense) on both machines and the "ProgramFiles" variable is identical on both machines.
"add the path to the dll to the "path" environment variable"
I'll consider this as a last resort. I'd rather not be changing system variables (unless it were to correct errors) to get something that should be simple fixed.
"try to place the dlls in the same folder as the application" & "consider to place the dll in the systems folder"
They are already in the folder with the application that they were delivered with; the fact that I'm also using them with the LabVIEW code is an add-on. I won't be moving them because I don't want to disturb the other application.
"Is the same version of windows running on both the systems?"
Yes, identical.
"Are you sure that on the development machine the dll is where you say it is, it might be that they are multiple copies of the dll and the VI maybe pulling in the dll from an alternative location."
There is only one copy of the DLLs on each machine. The message I'm getting about the where LV is looking for but not finding the files even confirms that. It's the exact same &*^%$#@ directory (or folder if you prefer) but in one case the path includes a logical variable replacement for "C:\Program Files" and in the other case it is explicitly spelled out.
"Has the VI, on the development system, got a * when you load it, indicating something has changed."
Yes the VI has changed, it's a natural result of it not having found the DLL where it thought it should be and my having to point it out again.
But that is the only reason it has changed. It's not from having being edited.
I should go on to say that all the VIs that make up the system reside in a folder hierarchy and they move back & forth between the two computers as a zipped (& numbered) archive of the top-level folder. If I change the LV system on one end or the other, I zip the whole mess up and move the zipped file to the other machine, trash the old LV system folder and unzip the revised folder hierarchy to a new set of folders.
