Jump to content

Weird looking prototype in CLFN


Recommended Posts

I'm trying to use a DLL which is developed by a third party.

I created wrappers using Import Shared Library Wizard.

 

When I call this function:

int _Initialize(char *ipAddress, int *cameraCount);

I get error 1097. I've checked the parameter setup, etc. I think it should be correct.

post-42734-0-49986600-1398171326_thumb.j

post-42734-0-74773800-1398171325_thumb.j

post-42734-0-99856300-1398171324_thumb.j

 

Only one thing seems a bit weird.If you look at the prototype definition in CLFN-configure window, the function name is something totally different than selected.

post-42734-0-00788700-1398170989_thumb.p

 

So, I'm wondering if this has anything to do with the actual problem?

 

Header looks like this:

#pragma once#include "PeakStructure.h"#include "Callback.h"#ifdef EXPORTING_DLLextern _declspec (dllexport) int _Initialize(char *ipAddress, int *cameraCount);#elseextern __declspec (dllimport) int _Initialize(char *ipAddress, int *cameraCount);#endif

 

 

Link to comment
I'm trying to use a DLL which is developed by a third party.

I created wrappers using Import Shared Library Wizard.

Only one thing seems a bit weird.If you look at the prototype definition in CLFN-configure window, the function name is something totally different than selected.

attachicon.gifclf_conf.png

 

That is C++ name mangling. The developer of the DLL forgot to tell the compiler/linker to not mangle the exported function names. It looks ugly and can be inconvinient but can't be the reason for your runtime error.

Looking at the function prototype and the CLN configuration I have to say that there is no obvious problem visible. I would rather suspect that the DLL needs to have another function called first before you are allowed to call this function. Or there is a bug in the DLL (well I would consider the possible requirement to first call another function before you can call Initialize() a bug in itself :lol: ).

  • Like 1
Link to comment

Thanks for the reply Rolf!

 

I forgot to mention that I have an example code written in C++. I compiled the example with Visual Studio and run it. Example seems to be working just fine. So I'm wondering, if it still could be a LabVIEW related issue?

Example code begins like this:

int _tmain(int argc, _TCHAR* argv[]){	CameraStatus status;	// Initialize the camera.	status = (CameraStatus) _Initialize("10.10.40.2", &_cameraCount);
Link to comment

Thanks for the reply Rolf!

 

I forgot to mention that I have an example code written in C++. I compiled the example with Visual Studio and run it. Example seems to be working just fine. So I'm wondering, if it still could be a LabVIEW related issue?

Example code begins like this:

int _tmain(int argc, _TCHAR* argv[]){	CameraStatus status;	// Initialize the camera.	status = (CameraStatus) _Initialize("10.10.40.2", &_cameraCount);

Hmmmm, that TCHAR in there!! Do you compile your test application as Unicode or ASCI?

Link to comment
Hmmmm, that TCHAR in there!! Do you compile your test application as Unicode or ASCI?

Thanks again Rolf, good call.

Yes, the project seems to be in Unicode. I've understood that LabVIEW currently only supports ASCII? So I guess would need to ask the DLL developer to compile the DLL as ASCII?

Link to comment
Thanks again Rolf, good call.

Yes, the project seems to be in Unicode. I've understood that LabVIEW currently only supports ASCII? So I guess would need to ask the DLL developer to compile the DLL as ASCII?

Well that is of course the most easy solution but maybe not the quickest :D . Alternatively you could make use of the unicode.llb library in this post.

Link to comment
  • 4 weeks later...
Well that is of course the most easy solution but maybe not the quickest :D . Alternatively you could make use of the unicode.llb library in this post.

 

I doubt that's the issue--using a unicode main() is the default for Visual Studio.  Many quick and dirty examples I've seen shipped by a vendor keep that (instead of changing to main and char*).  If you want to test this out... change their example's main to:

 

int main(int argc, const char* argv[]) {

 

Initialize() accepts a char* as it's first arg, so I'd doubt thats the issue.

Link to comment
I doubt that's the issue--using a unicode main() is the default for Visual Studio.  Many quick and dirty examples I've seen shipped by a vendor keep that (instead of changing to main and char*).  If you want to test this out... change their example's main to:

 

int main(int argc, const char* argv[]) {

 

Initialize() accepts a char* as it's first arg, so I'd doubt thats the issue.

 

Not sure what you try to say here. TCHAR is a Microsoft definition that will either use 16 bit UTF characters when UNICODE is defined or 8 bit ASCII characters when UNICODE is not defined. The only way to find out is by checking the project file for the test application. Depending on the Visual C version you can either set a specific property in the compiler settings that the code should be compiled as Unicode or not or you can also define the UNICODE explicitly yourself although that is likely to cause some problems at some point as other compiler options might depend some other things on the specific setting itself and not refer to a project define of UNICODE itself.

 

The problem is not about what Visual C uses by default for it's main function but how the test application (and ultimately the DLL) was compiled. It is also not entirely clear that _Initialize() uses char* for the parameter. The underscore in front of the function could just as well mean that the definition in the first post is not really taken from the header file but rather deducted from the Call Library Node dialog.

 

However I did a quick check of the name mangling shown in that picture and from that it seems to be indeed char* so not sure what else could be the issue here.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.