Project messed up due to LVOOP

[Eugen_Graf]

I think LV-RT couldn't find the DLL in the data-folder of the EXE. Why? How should I call a DLL and say (only if Exe) to take the DLL from data-folder.

Ok, I know, I can set the path for the CLFN and check if it's a Exe or not. But I think LV should do it automaticaly.

I mean I made more than 40 different projects with DLL callings and never got any problems.

But the problem is half-solved now. Thank you all.

Message Edited by Support on 12-01-2008 01:34 PM

[Eugen_Graf]

The one workaround to say to CLFN always to take the DLL from the Windows->System32 path and put the DLL into System32 folder using Installer.

What do you think about it?

Message Edited by Support on 12-01-2008 01:34 PM

[Intaris]

If it works, do it and document it.  If the customer doesn't complain then all is OK.

Shane. 

Message Edited by Support on 12-01-2008 01:34 PM

[Eugen_Graf]

I thank you, Shane and other peoples who  helped to solve that problem (Bug?)

И тебе, Андрей, спс за поддержку... Заходи к нам в форум, там у нас тоже прикольно. Есть русский, немецкий и английский форумы 

Message Edited by Support on 12-01-2008 01:35 PM

[Eugen_Graf]

I removed CAN Class from my project, I replaced Class control with a Typedef Cluster, I put the BD of library-VIs into the  subVIs. But it will not work. Now it seems the call of the DLL is wrong, but why? It works in LV IDE, but not as Exe.

What can be wrong? Path of the DLL? Any call parameters? What is the difference between DLL call from IDE and DLL call from the Exe?

Thank you

Message Edited by Eugen Graf on 11-24-2008 04:36 PM

Message Edited by Support on 12-01-2008 01:35 PM

[Matthew_Kelton]

If you put the directory your DLLs reside in your Path environment variable, then you also do not need to specify a path to the DLL, and LabVIEW will find the DLL.  You can set the path in LabVIEW using the WshShell ActiveX component if you want the setting up of the path to be automated (i.e. after install, you run an EXE to setup the path variable).  If you want to hardcode it in, then under Control Panel->System, go to Advanced, clikc the Environment Variables.  Path is listed under System Variables.  Just append a semi-colon and the path to the directory in which your DLL(s) reside, and LabVIEW will be able to find them.

I did it this way because I had several programs sharing the same DLLs, with 2 programmers writing code.  Doing this, we could move the DLLs at will as long as the path was correct, and as you said, I didn't have to worry about LV finding the DLLs after the install.

[Andrey_Dmitriev]

Hi, Eugen,

The statically linked DLL in the builded application usually searched in the following order (for example, application located in folder <YourApplication>\Application.exe):

1. Data subdirectory: <YourApplication>\data\YourDLL.dll

2. Inside of the application: <YourApplication>YourApplication.exe\YourDLL.dll

3. LabVIEW Runtime: <Program Files>\National Instruments\Shared\LabVIEW Run-Time\x.x\YourDLL.dll

4. Root application folder: <YourApplication>YourDLL.dll

5. System32 folder: <Windows>\System32\YourDLL.dll

6. system folder: <Windows>\system\YourDLL.dll

7. Windows root folder <Windows>\YourDLL.dll

8. Finally all folders, defined in PATH Variable

Normally all DLLs linked with VIs will be automatically placed to the \data subdirectory (except system DLLs or DLLs already included in LabVIEW runtime, etc).

In some cases this will not work (for example, you have DLL wrapper where another DLL will be called). In this case you can manually include all necessary DLLs to the project and set Support Directory for these files in the application builder settings.

Andrey.

Message Edited by Support on 12-01-2008 01:35 PM

[rolfk]

---

Andrey Dmitriev wrote:

Hi, Eugen,

The statically linked DLL in the builded application usually searched in the following order (for example, application located in folder <YourApplication>\Application.exe):

1. Data subdirectory: <YourApplication>\data\YourDLL.dll

2. Inside of the application: <YourApplication>YourApplication.exe\YourDLL.dll

3. LabVIEW Runtime: <Program Files>\National Instruments\Shared\LabVIEW Run-Time\x.x\YourDLL.dll

4. Root application folder: <YourApplication>YourDLL.dll

5. System32 folder: <Windows>\System32\YourDLL.dll

6. system folder: <Windows>\system\YourDLL.dll

7. Windows root folder <Windows>\YourDLL.dll

8. Finally all folders, defined in PATH Variable

Normally all DLLs linked with VIs will be automatically placed to the \data subdirectory (except system DLLs or DLLs already included in LabVIEW runtime, etc).

In some cases this will not work (for example, you have DLL wrapper where another DLL will be called). In this case you can manually include all necessary DLLs to the project and set Support Directory for these files in the application builder settings.

Andrey.

---

This is more or less correct with some caveats. First there is a step 0 too.

0) DLL already loaded into the process memory space, only the dll name itself is used, so absolute path has no effect.

1) is LabVIEW specific and doesn't need to be the data directory. I usually set the data directory in a build to the application directory (step 4) to make sure the DLLs are put in that directory and create additional custom subdirectories for plugin VIs and such that would otherwise get put into the data directory

2) two is not really possible. Windows does not really allow embedding DLLs into executable images

3) Not sure that 3 will actually happen for non NI DLLs, doesn't seem like a good place to put custom DLLs anyhow.

4) From here on standard windows loading applies. Not really sure that system folder will be searched for 32bit applications though.

Unless you have a separate installer for the software that installs the DLLs and all the dependancies somewhere and makes sure to install the user callable DLLs either in system32 or modifies the PATH environment variable correctly you should really resolve to making the support directory in a build to be the same as the application directory so all custom DLLs get put in that directory. Then create custom targets for other VIs and assign the dynamic VIs and such to be installed there instead of letting them be put in the support directory. If your LabVIEW called DLL needs other dependant DLLs add them as support file to the project and make them get installed in the application directory too. Resolves almost all DLL hell trouble you can ever encounter.

Rolf Kalbermatter

Message Edited by Support on 12-01-2008 01:35 PM

[Andrey_Dmitriev]

---

 Rolf Kalbermatter   wrote:

1) is LabVIEW specific and doesn't need to be the data directory. I usually set the data directory in a build to the application directory (step 4) to make sure the DLLs are put in that directory and create additional custom subdirectories for plugin VIs and such that would otherwise get put into the data directory

2) two is not really possible. Windows does not really allow embedding DLLs into executable images

3) Not sure that 3 will actually happen for non NI DLLs, doesn't seem like a good place to put custom DLLs anyhow.

4) From here on standard windows loading applies. Not really sure that system folder will be searched for 32bit applications though.

---

Fully agree with you, Rolf. The list above was obtained with tracking of the disk activities with FileMon during application launch. So, the application also will search DLL inside of application (or in the folder with same name as application), which is funny (and impossible, of course).

From my point of view \data\ subfolder is the best place for custom DLLs, which should be deployed with application.

System32 also may be used if loading from \data\ not possible, or DLLs already installed with third-party installer. In this case folders, defined in PATH variable also good.

Some points from the list above are documented:

My Stand-Alone Executable Cannot Find My DLL, Even Though I Have Specified the Path for the DLL

What is interesting - why DefaultDataFileLocation=<path> ini entry doesn't working in application?

Andrey.

Message Edited by Support on 11-25-2008 03:22 PM

[Eugen_Graf]

So, I made a very simple example using all driver VIs, which call this DLL and build an exe from this exapmle. I got no problems, no errors. So I can say the problem is not the call of the DLL. The DLL was automaticaly put in the data folder from Exe Builder and was found from the LV Run Time.

Message Edited by Eugen Graf on 11-25-2008 04:43 PM