Problem with DLL calling from LabView

[Porras]

Hi, all.

I want to call several functions compiled into a dll. The function prototype of one of them is this:

BOOL Initialize (char *configFile, char *coordFile, int &id);

To export the function, I use the following declaration:

extern "C" BOOL __declspec( dllexport ) Initialize (char *configFile, char *coordFile, int &id)

I use the Call Library Function Node. The entry points are correctly detected and I can select the name of this function within the dll. Then, I set the following parameters types:

return type:  signed 8-bit Integer

arg1:  C String Pointer

arg2:  C String Pointer

arg3:  Signed 32-bit Integer (pass by value)

When I run the VI, I get the following error message:

"Error 1097 occurred at Call Library Function Node. Possible reason(s):

LabVIEW:  An exception occurred within the external code called by a Call Library Function Node. The exception may have corrupted LabVIEW's memory. Save any work to a new location and restart LabVIEW."

The function Initialize deals with opening several dialog boxes and introducing information into them. Could this have caused this error?

Thanks in advance,

Francisco.

[smercurio_fc]

BOOL is most likely a 32-bit integer, so you should change the return type to I32. At least it is if you're referring to the BOOL defined in the standard Windows header files. What did you set the calling convention to? I assume you left it as "C"? Does the DLL try to update those character pointers?

Message Edited by smercurio_fc on 11-09-2009 01:13 PM

[mhs100]

Hi

I also faced the same problem, my problem was that i was using the wrong calling convention. Add _stdcall in your declaration and use the standard calling convention in labview. It may work.

For your guidance just write "Error 1097 in call library function" in the search box. I am sure that this thread will help you.

Regards

mhs100 

[Porras]

Hi, thanks for your fast reply.

At first, I was using C calling convention. Well, I've tried setting the return type to I32, adding __stdcall to the declaration and changing the calling convention (stdcall), but nothing new. The error remains. smercurio_fc, I think the character pointers are not updated (I don't really know, because I'm not the dll programmer, but I'm going to ask).

The dll's source code has been implemented using MFC. Maybe is there any kind of incompatibility between this library and LabView?

Thanks again,

Francisco

[smercurio_fc]

I'm a little confused. If you're not the DLL programmer, then how are you changing the calling method within the DLL?

[Porras]

Good question, smercurio_fc, hehe.

Well, I work on the LabView part but I'm in contact with the dll programmer and tell him the requirements that the source code has to match in order to be called from LabView.

[zou]

If you can mandate input/output data type, then change &id to *id:

_declspec (dllexport) BOOL Initial(char *configFile, char *coorFile, int *id);

see attached dll/VI.

George Zou

http://webspace.webring.com/people/og/gtoolbox/

[Porras]

Hello, Zou, thanks for your support.

First of all, I can't load your VI file because it's LV 9.0. Mine is LV 8.6. Could you please send me a compatible version?

Then, I created a simple VI with a Call Library Function Node and I tried to compile your C code to a dll, but I think I'm doing something wrong, because I get the same problem when trying to call it from LabView. At first, I get an empty validation window, then I press "OK", and the same error appears: "Error 1097 occurred at Call Library Function Node... "

However, I'm not sure about the correct procedure to get the dll in Microsoft Visual C++. How can I define the entry point? Is there no need to include the following piece of code? (because I only can see  in your file a DllMain function but is not declared in the same way):

// dllmain.cpp : Defines the entry point for the DLL application.
#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Thanks,

Francisco

Mensaje editado por Porras

Mensaje editado por Porras

[zou]

#include "stdafx.h"

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

Francisco,

Unless you want add some code in each case, otherwise you don't need them.

VI in LV8.6 is attached.

George Zou

http://webspace.webring.com/people/og/gtoolbox/

[Porras]

It's OK. Zou, your example works totally correct. So it's not a problem with LabView configuration or the way of calling the DLL (the VI I was using was identical).

So, the problem is in the DLL, then:

- Are there any aditional needs to compile the DLL when using MFC Class Library?

- Maybe, could be any incompatibility between DLL libraries using MFC which are not properly compiled and LabView? (I mean, if I am going to use a C++ function that uses MFC, do I have to compile it into a DLL in a different way unlike the procedure shown here, adding some extra code in DllMain or declaration, in order to be used in LabView?)

Thanks again,

Francisco

Mensaje editado por Porras

Mensaje editado por Porras

Mensaje editado por Porras