Labview 8.6 load dll issue

[Mathan]

Let's come to the problem. dll a can't find dll b.

Could you please tell whether any message coming? If so please give a screenshot. Is there any .lib file you are using?

Trying to help, 

Mathan

[rolfk]

---

adobefree wrote:

Hi mathan :

      Please allow me to say thank you again, you know i have got lots of information at  those dll problems(loading ascii c dll in LV or loading LV dll in c entironment ), this forum gave me great help to slove  this kinds of issue ,speciall in the 《Machine Vision》 child panel.

      Reffering to the problem i mentioned above , i can't post the whole dll based on the promise for customer technic security, can you just tell me what the common reason that how dose it happens?  i don't think there is some connection with the dll generation.

      Or any experiment you gona do ?  just tell me. 

thanks

---

So your DLL a seems to be a C function DLL exporting C functions you can link to with the CLN, ok! But what is DLL b???? Also a C function DLL, or an ActiveX DLL or maybe even a .Net DLL. While those all are DLLs technically, they have very different ways for Windows to look for them. LabVIEW only can and will go through extra lengths to locate the initial a.DLL. After that it's all out of the hands of LabVIEW and Windows will do the rest about looking for the dependant DLLs

For C function DLLs Windows will look only in these locations:

1) in memory using only the file name independant if the passed in path was absolute

2a) at the specific location if the path specified is an absolute path and fail if their isn't a loadable DLL.

From here Windows will only go further if the passed in name was a DLL name only without path.

2b)in the application directory for the current process (where yourapp.exe or in the case of the LabVIEW IDE LabVIEW.exe resides)

3) in the system directory

4) in the windows directory

5) in any directory that appears in the path environment variable

6) loading will fail with an error

This whole process will be repeated for every DLL that is referenced by the initial DLL or any dependant DLL and if one of them fails the entire load process will fail. Static references to DLLs will always be tried to be resolved using only the DLL name and never with an absolute name.

If it is an ActiveX DLL then Windows will look in the registry for a registered ActiveX component and otherwise fail, no matter where the DLL is.

If it is a .Net DLL then Windows will look first in the application directory for such a DLL and failing that it will look in the Global Assembly Cache (GAC). That is it in most cases except in LabVIEW which also makes Windows look specifically in the same directory as the current project file .lvproj is located.

So considering all this you have to first determine the type of DLL and then look at where you can place it. Except for ActiveX components (which always require a registration eg. installer) the prefered way for built executables is always to place dlls in the application directory.

Rolf Kalbermatter

Message Edited by rolfk on 03-26-2009 08:07 PM

[bo200008]

Hi adobefree,

As others mentioned, calling external dlls can be very different in different cases. With that being said, it is almost impossible to debug for others without it. I believe all respect your cecurity concern though that limits to what extent you can get helped.

Here are my suggestions:

1. For dll b, instead of compile it into dll, have you tried compile it into executable? Does that run well?

2. Have you tried calling dll b in other softwares? I used Matlab a lot for testing purpos. The point here is that you have to make sure the dll is working before blaming LV. 

3. If you write a dll wrapper in C, you can use LoadLibrary and FreeLibrary. Also, you need to get a reference to the function in dll a before calling them. This is the way I usually do it. Maybe there are some other ways as well. This process could a lot different for other programming languages.

These are my 2 cents. Good Luck!

[adobefree]

Hi All:

      i need to say sorry ,if the titile made your misunderstanding, i am not bleming LV, actually almost every problem I met was at last proved that LV is not the problem , the method i used is the root cause

      In my case , dll a(extern c dll) load dll b automaticly, dll b(c # COM component  ) will load dll c(vb,net)automaticly , i know it is a little bit complex, but i can load a dll in vs2003 exe , and a,b,c run fine.

      the only messagepop is from dll a:"Load COM component  fail!"  , following is the packing code of dll a, PhoneCommCOM class is from dll b

void _stdcall CommandType(int nType)
{
 CoInitialize(NULL);
 hRes = pP2K.CreateInstance(PhoneCommCOM::CLSID_PhoneCommCOMClass);
 if (hRes != S_OK)
 {
  AfxMessageBox(_T("Load COM component  fail!"));
  return;
 }

 pP2K->CommandType(0);
}

 so i guess, dll a can't find dll b

   by the way ,when we build a dll in LV ,the srtuct define can't be changed , allways like "TD1,TD2,TD3.......",i have to modify the .h file, is there any way to define in LV interface?

thanks

[adobefree]

i want to upload the vs2003 dll a project ,  dlltest project ,and the dll b and c, how can i give you the zip extract password?  i mean how to send forum message personally?  

[RavensFan]

---

adobefree wrote:

i want to upload the vs2003 dll a project ,  dlltest project ,and the dll b and c, how can i give you the zip extract password?  i mean how to send forum message personally?  

---

Use the Add Attachments link underneath the editor window then browse to the file you want to upload.