teststand call a DLL, which will call another DLL

[gavin.gqchen]

Hi,

I have a dll from vendor (Lineeye LEPCLIB.dll).  I will need to create a DLL (MyDLL) using labwindows CVI which will call LEPCLIB.dll in the code.

Everything is OK after build and I can use an external exe file to call Mydll and it will call LEPCLIB.dll sucessfully. 

However, we I use teststand 2010 to call Mydll, calling Mydll itself is no problem but when calling fundtions in LEPCLIB.dll, it always return error. Seems something in teststand for dll calling.

All DLL are already put to same path in local pc. I also tried to put those dll to system32 folder and it did not work either.

Anyone can help about this strange issue?

Thanks in advance.

Gavin

DLL function in MyDLL:

void __declspec(dllexport) __stdcall CPRI_TEST(tTestData *testData, tTestError *testError)
{

int error = 0;
int i=0;
int iStatus = 0;
char szTemp[32] = {'\0'};

LE_SETUP le_setup;

//********************************************************************************************************

// function from LEPCLIB.dll.

//if using exe to call this dll, everything is OK, but if using teststand to call this dll, here will return error

//********************************************************************************************************

error = LEConnect("38111008"); 

if(error != 1)
{

sprintf(szTemp, "Loop count %d, Connecting Failed", i);
MessagePopup ("error", szTemp);
break;

}
}

int __declspec(dllexport) __stdcall DllMain (HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:

/* Respond to DLL loading by initializing the RTE */
if (InitCVIRTE (hinstDLL, 0, 0) == 0)
return 0;
break;
case DLL_PROCESS_DETACH:

/* Respond to DLL unloading by closing the RTE for its use */
if (!CVIRTEHasBeenDetached ())
CloseCVIRTE ();
break;
}

/* Return 1 to indicate successful initialization */
return 1;
}

[James_Grey]

Try creating a windows shortcut to whatever TestStand application you use... such as SeqEdit.exe. Set the Start In property of the shortcut to be the directory that contains the .exe you built that calls the dlls successfully.

If that works, then there are other dependent dlls that weren't in the Windows search path when you tried it from System32. Perhaps LEPCLIB.dll depends on yet another dll in the original directory? You might use the Microsoft Depends utility, or similar tool to determine the missing dependencies.

[dug9000]

What is the error you get? What is giving the error? The function in the other dll? If the function is giving the error, then the dll is probably being loaded ok, but failure for a different reason. If you can get as much details as possible about what the error means that might help. TestStand threads being initialized as MTA for COM can sometimes lead to issues with dlls that are also using COM, but are expecting STA threads. There are workarounds for this if that is the problem, but knowing as much details as possible about the error you are getting might help determine what the problem is.

-Doug

[gavin.gqchen]

Hi,

The function is in another dll. I can get the return value from that function and it is error. There is not much inforamtion about what this return value means  based on the release notes. 

I think the dll is loaded sucessfully but some other issue causes this problem. It should not be caused by missing supporting dll(I tried using exe to call it and it's OK, all dlls are in same folder).

What does you mean about the workarounds? Could you please give me more information and maybe I can have a trial?

Thanks a lot.

BR

Gavin

[dug9000]

---

@gavin.gqchen wrote:

Hi,

The function is in another dll. I can get the return value from that function and it is error. There is not much inforamtion about what this return value means  based on the release notes. 

I think the dll is loaded sucessfully but some other issue causes this problem. It should not be caused by missing supporting dll(I tried using exe to call it and it's OK, all dlls are in same folder).

What does you mean about the workarounds? Could you please give me more information and maybe I can have a trial?

Thanks a lot.

BR

Gavin

---

To see if it's related to the COM threading model, you can create a main sequence that calls your real mainsequence in a new thread with the advanced option to "Use Single-Threaded Apartment" checked. Add a wait step after the "new thread" sequence call to immediately wait for the thread to make it synchronous.

Let me know if you need more details than this.

-Doug